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Executive Summary 


This report describes a trade study of roles and responsibilities associated with the 
Management by Trajectory (MBT) concept. The MBT concept describes roles, responsibilities, 
and information and automation requirements for providing air traffic controllers and managers 
the ability to quickly generate, evaluate and implement changes to an aircraft’s trajectory. In 
addition, the MBT concept describes mechanisms for imposing constraints on flight operator- 
preferred trajectories only to the extent necessary to maintain safe and efficient traffic flows, and 
the concept provides a method for the exchange of trajectory information between ground 
automation systems and the aircraft that allows for trajectory synchronization and trajectory 
negotiation. 

The participant roles considered in this trade study include: airline dispatcher, flight crew, 
radar controller, traffic manager, and Air Traffic Control System Command Center (ATCSCC) 
traffic management specialists. 

The proposed allocation of roles and responsibilities was based on analysis of several use 
cases that were developed for this purpose as well as for walking through concept elements. 
The resulting allocation of roles and responsibilities reflects both increased automation 
capability to support many aviation functions, as well as increased flexibility to assign 
responsibilities to different participants — in many cases afforded by the increased automation 
capabilities. Note that the selection of participants to consider for allocation of each function is 
necessarily rooted in the current environment, in that MBT is envisioned as an evolution of the 
National Airspace System (NAS), and not a revolution. 

A key feature of the MBT allocations is a vision for the traffic management specialist to take 
on a greater role. This is facilitated by the vision that separation management functions, in 
addition to traffic management functions, will be carried out as trajectory management functions. 
This creates an opportunity for flexibility, allowing the traffic management specialist to carry out 
tasks that today can only be carried out by the controller currently in contact with the aircraft. 

This additional tasking for the traffic management specialist comes with requirements for 
workload management. An increased role for the Data-side (D-side) controller relative to the 
Radar-side (R-side) controller is a potential approach to mitigating workload for the traffic 
management specialist, as the D-side controller would have similar ability to perform separation 
management functions in what today might be considered the “trajectory management” 
timeframe. This analysis did not distinguish between the D-side and R-side controllers since in 
many cases the R-side controller works unassisted. 
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1. Introduction 


In the current operational environment, air traffic control (ATC) automation, such as arrival 
and departure schedulers in the Time Based Flow Management (TBFM) system, develops plans 
based on aircraft trajectory predictions using available information such as aircraft performance 
and winds/weather. However, once that plan is in place, controllers tactically manage the 
aircraft, using vectors, altitude, or speed clearances, to either conform to the schedule at control 
points or to address other issues that come up, such as maintaining separation, or changing 
weather conditions. Since these tactical actions are not directly communicated to the 
automation systems, the underlying trajectories may not be properly updated, which can lead to 
inefficiencies in the air traffic system. Although aircraft are equipped with many capabilities to 
predict and fly a trajectory, the controller’s tactical instructions often prevent full use of these 
capabilities. 

In order to realize the full NextGen potential, there needs to be better coordination between 
air navigation service providers (ANSPs) and system users (e.g., pilots and airline dispatchers) 
in terms of better managing aircraft along planned trajectories. Future automation improvements 
and increased data communications between aircraft and ground automation would make this 
idea of Management by Trajectory (MBT) possible. Key components of an MBT concept 
include: 

e The ability for air traffic controllers and managers to quickly generate, evaluate and 
implement changes to an aircraft’s trajectory. 

e Imposing constraints on flight operator-preferred trajectories only to the extent 
necessary to maintain safe and efficient traffic flows. 

e A method for the exchange of trajectory information between ground automation 
systems and the aircraft that allows for trajectory synchronization and trajectory 
negotiation. 

The MBT concept is an evolution of the current National Airspace System (NAS) and 
describes roles, responsibilities, and information and automation requirements consistent with 
that vision. This report describes an analysis examining the allocation of roles and 
responsibilities among human participants and automation. The participant roles considered 
include: airline dispatcher, flight crew, radar controller, traffic manager, and Air Traffic Control 
System Command Center (ATCSCC) traffic management specialists. The report seeks to 
identify the best distribution of roles and responsibilities, as well as information and automation 
support requirements for each participant. 


it. Objectives 


The objectives of the trade study are to identify the best distribution of MBT roles and 
responsibilities among human participants, as well as information and automation support 
requirements for each participant. Since MBT is envisioned as an evolution of the current NAS, 
the distribution of roles and responsibilities is scoped to provide an evolution from the current 
responsibilities of a given role to the responsibilities envisioned for MBT. As such, the trade 
study did not consist of an exhaustive analysis that considered all possible allocations of each 
responsibility. 


1.2. Document organization 


This document is organized as follows: 

Section 2 describes the approach for carrying out the trade study. 

Section 3 provides a high level summary of each of the use cases. 

Section 4 provides a high level description of each of the participants and their 
responsibilities in the current National Airspace System (NAS). 

Section 5 summarizes the key MBT functions and their allocation to participants. 


Section 6 summarizes the conclusions and recommendations. 

Section 7 provides a list of acronyms used in the report. 

Section 8 provides the bibliography for the report. 

Appendix A describes the use cases that formed the basis of the analysis and the functions 
and allocations associated with each use case. 


2. Trade Study Approach 


The trade study started from an assumption that the key participants in the NAS will not 
change significantly in the future, even if their responsibilities change. In particular, the trade 
study is focused on the following roles: 

Air traffic controllers 

Flight crews 

Flight dispatchers 

Flight operator ATC coordinators 

Field facility Traffic Management Coordinators (TMC) 
ATCSCC Traffic Management Specialists 

The distribution of roles and responsibilities was explored through a series of scenarios and 
use cases focused on the goals of MBT. These scenarios were derived based on operational 
reasons why the above concept components are necessary. For example: 

e Anaircraft’s trajectory may need to be modified for a number of reasons; MBT is 
particularly focused on those that in today’s environment result in aircraft operating on 
open trajectories. 

e There are several operational reasons why constraints must be imposed on flight 
operator-preferred trajectories (e.g., traffic management initiatives); MBT is particularly 
focused on those that may over-constrain the trajectories. 

e Trajectory synchronization supports trajectory conformance monitoring and is required to 
maintain closed clearances; MBT is focused on operational scenarios that in today’s 
environment result in non-synchronized trajectories. 

e Trajectory negotiation is a key aspect of TBO, and negotiation is required in each of the 
above sets of operational scenarios. Thus, methods for carrying out the negotiation must 
be considered in each of the scenarios and use cases. 

Where relevant, multiple use cases were developed to explore each scenario area. 

Note that the process of developing the use cases required the research team to make 
some concept design decisions that may not be fully documented in the trade study results. The 
use case development process served to illustrate the MBT concept as it was being defined, 
and therefore some decisions that were made to solve the problems presented in the use cases 
made the allocation of roles and responsibilities seem clear, and constraining what the research 
team considered as candidate allocations. This could be viewed as a flaw in the trade study, 
since it makes it appear as if alternate allocations were not considered. However, the approach 
usefully scoped the effort, grounding the trade study (and the MBT concept) in operationally 
valid contexts. Note that in other cases, such as the example of a weather deviation, the 
approach actually helped the team to consider a wider range of possible allocations of 
responsibilities than it might have otherwise. 

The scenarios and use cases drove the identification of MBT functions needed to carry out 
the concept, and the responsibilities associated with those functions. Each use case illustrated a 
candidate allocation of these responsibilities to different participants and a high level description 
of required automation capabilities. In many cases, the allocation of responsibilities is context- 
dependent, and also may vary according to flight operator organizational design (e.g., some 
flight crews are not supported by a Flight Operations Center). 

After developing the use cases and candidate allocations of roles and responsibilities, the 
research team conducted a cognitive walkthrough to engage subject matter experts (SMEs) in 
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providing feedback on the MBT concept, reviewing the automation support requirements, and 
validating the allocation of roles and responsibilities. 

Note that the candidate allocations of roles and responsibilities are somewhat constrained 
by what is considered feasible based on the current system design. For example, assigning 
primary responsibility for separation management to any role other than a controller would be 
such a departure from the current system design that it would make implementation of the MBT 
concept much more difficult in the absence of significant justification. Thus, some possible 
allocations of responsibilities were not entertained. 


3. Summary of Use Cases 


The use cases and the associated functions are described in detail in Appendix A, but are 
summarized here for the reader. 

Controller Issues a Vector for Traffic: Two aircraft are in conflict. In the current 
environment, the controller issues a vector that puts one or both aircraft onto an open trajectory. 
In the MBT environment, the controller has tools that support resolving the conflict while keeping 
both aircraft on a closed trajectory. 

Controller Issues an Interim Altitude for Traffic: This is a variation on the previous use 
case in which two aircraft are in conflict. In the current environment, the controller issues an 
interim altitude that puts one aircraft on an open trajectory. In the MBT environment, the 
controller has tools that support resolving the conflict while keeping both aircraft on a closed 
trajectory. 

Controller Issues Vectors for Miles in Trail (MIT) Sequencing: A downstream Air Route 
Traffic Control Center (ARTCC) has passed back a 20 MIT restriction. In the current 
environment, the controller issues a speed reduction and/or a vector to achieve the required 
spacing before handing the aircraft off to the next ARTCC. In the MBT environment, the 
controller has tools that support spacing and sequencing while keeping all aircraft on closed 
trajectories. 

Controller Issues Vectors for Time Based Metering: A downstream ARTCC has initiated 
adjacent center metering. In the current environment, the controller issues a speed reduction 
and/or a vector to achieve the required metering delay before handing the aircraft off to the next 
sector. In the MBT environment, spacing and sequencing can be accomplished by applying 
constraints to aircraft trajectories. 

Pilot Requests Deviation for Weather: In this use case, a pilot requests a deviation 
around weather that he/she sees out the window but is not visible on the ground automation 
radar. In the current environment, the aircraft is on an open trajectory while deviating, creating 
significant downstream uncertainty. MBT leverages advanced flight deck capabilities to support 
the pilot requesting a closed weather avoidance trajectory. 

Dispatcher Requests Reroute for Special Activity Airspace Restriction: A dispatcher 
requests a more efficient route for a flight when a Special Activity Airspace (SAA) is made 
available. The SAA affects a busy aviation corridor. In the current environment, it is difficult to 
coordinate reroutes through the SAA, but improved planning capabilities and trajectory 
predictions in the MBT environment allow more aircraft to negotiate a more efficient trajectory. 

Dispatcher Requests Delayed Arrival for Gate Management: A dispatcher requests that 
a flight crew reduce in flight speed in order to delay their arrival time for gate management. 
However, the aircraft encounters higher than expected headwind and therefore absorbs more 
delay than expected. Furthermore, the extra delay pushes the aircraft into a heavy arrival bank 
that is exacerbated by weather. In the current environment, this aircraft encounters significant 
delay and airborne holding. In the MBT environment, the aircraft experiences less delay. 

Use of Collaborative Trajectory Options Program to Manage Multiple Constraints: A 
Collaborative Trajectory Options Program (CTOP) Traffic Management Initiative (TMI) is used to 
manage a large, dynamic weather event that significantly disrupts NAS operations. In the 


current environment, use of Trajectory Options Sets (TOSs) is limited to pre-departure, and en 
route adjustment due to changing constraints is difficult. MBT Supports a more dynamic 
response to changing constraints. 


4. Management by Trajectory Participants 


This section provides a high level description of the MBT participants and their roles in 
today’s NAS. 


4.1. Air Traffic Controllers 


In today’s NAS, air traffic controllers are responsible for maintaining a safe and expeditious 
flow of traffic. They use various decision support tools to develop a mental image of the traffic 
operating in their sector and nearing handoff to their sector. They use this image to mentally 
develop a plan for tactically maneuvering aircraft as needed to maintain safe separation while 
also meeting traffic management goals such as sequencing and separation. They employ 
various tactics to achieve those goals, including: 

e Vectors to stretch an aircraft's path 

e Speed controls 

e Altitude constraints, including leveling off during climb or descent 

The aim of these tactics is typically to delay the aircraft's arrival to a given point — typically a 
conflict point, meter fix, or sector boundary — by the required amount. 

In today’s environment, controllers do not consistently update flight plans to account for 
tactical maneuvering for separation or weather deviations. Whereas controllers typically have a 
plan in place for when and how the aircraft in question will return to its flight plan route, they do 
not routinely communicate that intent to the pilot or to any automation tools. As a result, the 
ground automation trajectory prediction algorithms attempt to model the aircraft's return to its 
flight plan route using models of controller behavior built into the tools [1]. 


4.2. Flight Crew 


The flight crew is responsible for safely operating the aircraft and complying with procedures 
and ATC instructions. They are expected to “see and avoid” other air traffic, and in some limited 
cases are responsible for maintaining separation with other aircraft (e.g., when operating in 
uncontrolled airspace). 

Flight crews also have business goals associated with their operation of the aircraft. Air 
transport pilots often are expected by their companies to operate the aircraft efficiently (i.e., 
minimize fuel consumption and flight time), whereas business aviation pilots may be expected to 
arrive to the destination as quickly as possible. Other general aviation pilots may operate with 
other goals, such as enjoying the experience of flying. These goals, along with the aircraft 
performance characteristics, affect the way in which a flight crew will plan their flight and 
respond to ATC instructions. 

In addition, different aircraft have different capabilities. Thus, any vision for the NAS must 
address the mix of equipage that is expected in the environment, including aircraft capabilities 
associated with: 

e Navigation precision, such as Required Navigation Precision (RNP) and Area Navigation 

(RNAV) capabilities 

e Time of arrival control, such as Required Time of Arrival (RTA) compliance capabilities 

e Use of a Flight Management System (FMS) and its capabilities to manage different 

phases of flight automatically 

e Downlink of data to the ground, including performance and intent data 

e Receipt of uplinked data, including ATC clearances 


Most domestic air transport flight crews, and some business aviation flight crews, also are 
required to coordinate flight decisions with a dispatcher. This may increase the time required for 
a flight crew to accept a clearance received from ATC. 


4.3. Airline Dispatcher 


Dispatchers are jointly responsible for the safe operation of the aircraft from gate to gate. 
They produce a flight plan that meets safety, efficiency, and other business goals, including 
required fuel to account for contingency operations. They coordinate decisions regarding 
conduct of the flight with the flight crew, providing a wider system view than what is available to 
the flight crew (especially en route). They incorporate information about route constraints into 
the flight plan and can provide that perspective to the flight crew during en route decision 
making. 

However, dispatchers are limited by the decision support tools they have, which are typically 
designed for pre-departure flight planning. (Although note that new generation flight planning 
tools will have improved support for en route flight reoptimization.) They also have access to a 
great deal of information about NAS operations and constraints, but they typically must use their 
judgment when planning a flight to anticipate the effects of those NAS constraints on a given 
flight. For example, they may not know what reroute a flight will be given to avoid a given 
weather system, but they must anticipate a reroute in order to plan an appropriate amount of 
fuel and an appropriate alternative airport(s) in case of a deviation. 


4.4, Airline ATC Coordinator 


Whereas the dispatcher is jointly responsible for the safe operation of individual flights, the 
ATC coordinator typically is responsible for managing the flight operator network in response to 
NAS constraints and Traffic Flow Management (TFM) actions. The ATC coordinator also listens 
to TFM planning teleconferences and participates to the extent possible (although officially flight 
operators are listening parties and not given a decision making role). The ATC coordinator also 
contacts the ATCSCC and ARTCC Traffic Management Unit (TMU) as needed to coordinate 
specific flights and/or local operations (e.g., where the airline is the dominant flight operator). 

The ATC Coordinator uses NAS information made available by the FAA such as through 
TFMData and Collaborative Decision Making (CDM) tools, as well as company tools to monitor 
the flight network and manage recovery operations, particularly in response to disruptive events 
such as large weather systems. 


4.5. Traffic Management 


The mission of the Traffic Management System is to balance air traffic demand with system 
capacity to ensure the maximum efficient utilization of the National Airspace System (NAS). A 
safe, orderly, and expeditious flow of traffic while minimizing delays, is fostered through 
continued analysis, coordination, and dynamic utilization of TMIs. In an MBT environment, the 
roles and responsibilities of both the ATCSCC and all field facility TMUs increase due to the 
importance of TFM in achieving MBT goals. 


4.5.1 Air Traffic Control System Command Center (ATCSCC) 


The Air Traffic Control System Command Center (ATCSCC) has been delegated the 
authority to direct the operation of the TFM system. The ATCSCC must, in conjunction with field 
facility TMUs, users, weather information providers, and airway facilities, as appropriate: 

e Implement national TFM programs, when necessary, to ensure the orderly flow of traffic 

throughout the NAS. 

e Monitor and analyze system components and weather patterns for potential system 

impact. 


e Determine when NAS capacity is or will likely be reduced to the extent that the 
implementation of a TMI is required. 

e Monitor TMIs issued throughout the system for effectiveness and take action to cancel or 
modify initiatives where appropriate. 


4.5.2 Air Route Traffic Control Center/Terminal Radar Control Traffic 
Management Unit 


Air Route Traffic Control Center/Terminal Radar Control (ARTCC/TRACON) traffic 
managers are responsible for monitoring and balancing traffic flows within their areas of 
responsibility, which is accomplished using a suite of specialized traffic management tools and 
programs. Field facility Traffic Management Units (TMUs) must: 

e =In conjunction with the ATCSCC, adjacent ATC facilities, air traffic controllers, Area 
Supervisors/ Managers, weather service providers, and users, implement, monitor, and 
analyze TFM programs, procedures, and initiatives that are specific to the facility’s area 
of responsibility. 

e Work together to develop arrival strategies and deliver aircraft to achieve the Airport 
Arrival Rate (AAR). 

e Actively utilize the Traffic Situation Display (TSD) and the monitor alert function to adjust 
traffic flows in order to keep all sectors safe and manageable. 

e Balance the flow of arrival, departure and enroute traffic by coordinating with the 
ATCSCC and appropriate adjoining facilities, to ensure that demand does not exceed 
current capabilities. 


5. Key Management by Trajectory (MBT) Functions 


This section summarizes the MBT functions and allocations and contrasts the MBT 
allocations with the current environment. The functions discussed here were derived from the 
analysis of the use cases described in Appendix A. Only those functions whose allocations are 
affected by MBT or are otherwise relevant to this report are discussed here. Note that the 
selection of participants to consider for allocation of each function is necessarily rooted in the 
current environment, in that MBT is envisioned as an evolution of the NAS, and not a revolution. 
An additional goal of the allocation is that the role(s) with the best access to the necessary 
information be given responsibility for carrying out the function [2]. 

The allocation of a specific function in many cases depends on context. That is why the 
functions are discussed in context of the use case(s) to which they are relevant, with some 
generalizations made to a larger context where applicable. 

A key feature of the MBT allocations is a vision for the traffic management specialist to take 
on a greater role. This is facilitated by the vision that separation management functions, in 
addition to traffic management functions, will be carried out as trajectory management functions 
(see Figure 1). This creates an opportunity for flexibility, allowing the traffic management 
specialist to carry out tasks that today can only be carried out by the controller currently in 
contact with the aircraft. 
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Flow Management Trajectory Separation Collision 


Management Avoidance 


Management 


Traffic managers assess TMls are executed by Controller provides Pilots and aircraft 

NAS constraints, modifying flight instructions that prevent automation maneuver 

evaluate alternatives, trajectories, e.g., by and/or resolve conflicts "at the last minute” to 

and implement TMIs applying CTAs and avoid a collision 
STAs. 


Figure 1: Current-day Trajectory Timeline 


This additional tasking for the traffic management specialist comes with requirements for 
workload management. An increased role for the D-side controller relative to the R-side 
controller is a potential approach to mitigating workload for the traffic management specialist, as 
the D-side controller would have similar ability to perform separation management functions in 
what today might be considered the “trajectory management” timeframe. This analysis did not 
distinguish between the D-side and R-side controllers since in many cases the R-side controller 
works unassisted. 

Note that automation is never a responsible stakeholder [3]. In situations in which an 
automation system is expected to be the primary participant performing a function, the human 
role being supported by the automation will likely actually be held responsible for ensuring that 
the function is carried out appropriately. Thus, these functions are allocated to the human 
participant expected to be held responsible for ensuring that the automation completes the task 
appropriately. The automation requirements are discussed in the text. 


5.1. Amend Assigned Trajectories 


This function refers to the act of updating the assigned trajectory in the automation, after the 
trajectory has been planned and negotiated (if negotiation is appropriate in context). In the MBT 
environment, this function is allocated to the controller in some cases and the traffic 
management specialist in others, essentially depending on which participant is closest to the 
process of identifying and resolving the issue requiring a trajectory amendment. 


5.1.1 Controller Responsibility 


In the current environment, the assigned trajectory (i.e., the flight plan) is not amended in 
conflict avoidance scenarios — hence, aircraft are on open trajectories while executing the 
conflict avoidance clearance. An important change in the MBT environment is that the assigned 
trajectory will be updated every time an aircraft is required to do something different. 

In conflict avoidance scenarios, it is expected that controller automation will amend the 
assigned trajectory based on the conflict resolution clearance delivered by the controller. That 
is, the controller's act of uplinking the clearance to the flight deck and the pilot’s act of accepting 
the clearance cause the controller automation to update the assigned trajectory with the 
amendment. Thus, the controller is given primary responsibility for this function in conflict 
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avoidance scenarios (i.e., the controller is responsible for making sure the assigned trajectory is 
amended when providing a conflict avoidance clearance). 

Automating this function will help ensure that the clearances are closed. It is important to 
note that adding responsibility to the controller for entering all clearances provided by voice into 
the automation has consequences. First, controllers may be more likely to accept the automated 
solution to avoid manually entering information into the automation, which requires that the 
automation provides adequate solutions (and makes it desirable for automation to consistently 
provide solutions that are as good as or better than those the controller would propose). More 
consistent use of automated conflict resolution advisories may decrease controllers’ skill at 
detecting and resolving conflicts manually, which could present a safety issue if controllers are 
expected to be the safety net in the case of automation failure. 

If a controller has to enter a clearance manually into the automation, it is important that not 
only is the automation designed to make that easy, but having the information in the automation 
also must provide a benefit to controllers. Research has shown that when people are expected 
to enter data into automation to support others with no benefit to themselves, it is not likely that 
they will do so [4]. Thus, to support closed clearances, the controller automation should be 
designed with the following goals in mind: 

e Amend assigned trajectory without explicit controller action to the extent possible. 

e Facilitate easy assigned trajectory amendment in cases where controller must enter 

information manually. 


5.1.2 Traffic Management Specialist Responsibility 


When the trajectory amendment is the result of a dispatcher request and/or negotiation with 
traffic management, the traffic management automation that carries out the negotiation is 
expected to amend the assigned trajectory when the negotiation is complete. Thus, the ARTCC 
or ATCSCC traffic management specialist is primarily responsible for ensuring that the assigned 
trajectory is amended as the result of the negotiation. The emphasis on traffic management 
involvement in the negotiation here reflects the desire to identify and resolve issues with the 
assigned trajectory as early as practical, such that the issue being resolved is far downstream 
from the aircraft's current position — and the associated trajectory amendment does not affect 
any controller’s planning horizon. Note that the controller would be responsible for amending the 
trajectory if the trajectory change occurred within the controller’s planning horizon. 

In the current environment, many flight plan amendments must be entered manually into the 
controller or traffic management automation by a controller or traffic management specialist. In 
an MBT environment, it is expected that traffic management automation can engage in 
trajectory negotiation with flight operators and can thus amend the assigned trajectory at the 
conclusion of the negotiation according to parameters set by the traffic management specialist. 

However, controller automation will not be expected to negotiate this kind of assigned 
trajectory amendment and therefore the controller would need to take a separate action to use 
the controller automation to evaluate and amend the assigned trajectory. Note that this is similar 
to the conflict avoidance maneuvers discussed above, in which the explicit action taken by the 
controller was to uplink a clearance to the aircraft and this action also triggered amendment of 
the assigned trajectory. 

Traffic management specialists will have equal authority to amend the assigned trajectory to 
what they have today, but it is expected that in the MBT environment they will be primarily 
responsible for managing the process by which the traffic management automation negotiates 
trajectories and amends the assigned trajectories. 


5.2. Apply Constraints to Aircraft Trajectories 


A key differentiator of MBT from other concepts is the use of trajectory constraints to 
implement TMIs and other effects of airspace constraints. This function applies at two levels: 1) 
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associating NAS constraints with affected aircraft trajectories; and 2) specifying the effect of the 
NAS constraint on the trajectory by adding or modifying trajectory constraints. 


5.2.1 Apply NAS Constraints 


Since NAS constraints are applied by traffic management, only the traffic management 
specialist was considered to carry out the responsibility of associating NAS constraints with 
individual aircraft trajectories. Traffic management automation does this today for TMIs that are 
effected through CDM processes as well as TBFM; the automation identifies affected aircraft 
and computes control times — trajectory constraints — for them to meet. 

However, MIT is a frequently used TMI in the current environment. Traffic management 
specialists create the TMI and controllers are expected to hand off aircraft at the specified 
location with the required spacing. This is a manual process for the controllers. In the MBT 
environment, the traffic management automation also should automatically apply a reference to 
the MIT constraint to the affected aircraft when the traffic management specialist implements 
the MIT constraint. 

The case of an SAA that reopens highlights the importance of associating NAS constraints 
with the trajectory independently of the specific trajectory constraints. In this use case, assigned 
trajectories avoid the affected airspace, but it is desirable to have some way to quickly identify 
aircraft that could use the airspace once it becomes available. This creates opportunities to 
make more efficient use of the NAS. 


5.2.2 Apply Trajectory Constraints 


As for applying trajectory constraints reflecting the effect of the NAS constraint on individual 
trajectories, the participant responsible depends on the type of NAS constraint and what is 
required of the aircraft to meet the constraint. For TMls like the CDM programs noted above, the 
traffic management automation already performs this function and therefore the traffic 
management specialist is responsible in the current environment. No need to change this 
allocation is suggested in the MBT environment. 

Constraints are not applied to trajectories to implement MIT in the current environment, but it 
is expected that they will be in an MBT environment. There are multiple different constraints that 
can be applied to individual aircraft trajectories to achieve the desired spacing. For example, 
aircraft can be provided crossing time constraints that would provide 20 MIT between pairs of 
aircraft on the same flow, or appropriately equipped aircraft could maintain the necessary 
spacing using interval management. Traffic management automation could identify and apply 
either kind of trajectory constraint when the traffic management specialist implements the MIT 
TMI. Thus, the traffic management specialist would be responsible in this case. 

Alternatively, the controller could be given flexibility to choose the approach to take. Or, as 
in the Vectors for MIT Sequencing use case, the aircraft could be handed off to the controller 
without the necessary spacing. In such cases, the controller must take responsibility for 
identifying the pairs of aircraft to be sequenced and achieving the needed spacing. 

Both traffic management and controller automation need to identify pairs of aircraft that 
require trajectory amendments to achieve the spacing requirement. A key open question is a 
precise definition of the handoff of responsibility for this function from the traffic management 
specialist to the controller such that both do not simultaneously attempt to solve the same 
problem. 

Whether it is the controller or the traffic management specialist identifying the affected 
aircraft, automation should support precise calculation of the spacing that will be achieved 
without trajectory amendments, immediate identification of aircraft that require trajectory 
amendments to achieve the required spacing, as well as support for planning the trajectory 
amendments. 
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5,3. Deliver Clearance 


In the current environment, only the controller can deliver a clearance to an aircraft. 
However, Data Link and other forms of advanced data exchange create the possibility for other 
approaches to delivering clearances. The primary approach to delivering clearances in an MBT 
environment will be delivery from the controller via controller automation (i.e., Data Link). But 
when constraints are applied to trajectories due to traffic management programs, the trajectory 
amendment could be delivered by the traffic management specialist via traffic management 
automation. Previous research has proposed the following requirements for traffic management 
delivery of a clearance [5]: 

e The reroute does not affect the aircraft route or speed in the sector of the controller 

currently responsible for the aircraft. 

e The trajectory change point is at least two sectors away and one hour of flight time 
away. 

e The controller currently responsible for the flight needs to have access to information 
about the downstream trajectory change in case the flight crew asks about the new 
clearance. 

e Ifthe ARTCC TMU does not issue the clearance early enough, the clearance is sent to 
the controller to deliver. 

e The aircraft must be within the geographical boundary of the ARTCC TMU delivering the 
clearance and under direct control of one of its sectors. 

e The automation should prevent situations in which both the TMU and the controller in 
charge of the aircraft simultaneously issue a clearance. 

e The flight crew acknowledgment of the amended clearance should only be received by 
the TMU that issued the clearance. 

Further research is needed to quantify performance associated with traffic management 

delivery of clearances in various scenarios, including application of constraints to aircraft 
trajectories to meet traffic management program goals. 


5.4. Detect Conflict 


Controllers will retain responsibility for conflict detection in the MBT environment, but MBT 
will allow the automation they use to be much more reliable than it is today. Cognitive 
walkthrough controller participants stressed that in the current environment they are not likely to 
use their strategic conflict detection capability for several reasons. Critically, the strategic tool 
does not have access to all of the data it needs to produce an accurate trajectory prediction. For 
example, if a climbing aircraft has been leveled off by the controller in the previous sector, the 
controller receiving the strategic conflict alert knows that the previous sector controller will 
continue the aircraft’s climb before handing it off. However, the strategic conflict probe does not 
know the aircraft will continue its climb. MBT conflict detection automation will require access to 
the updated assigned trajectory and the ability to share trajectory changes across sectors. The 
core of the MBT concept, i.e., applying constraints to the assigned trajectory to effect change in 
the trajectory, will support the controller automation in meeting these requirements. 

The controller participants also noted that if controller automation is to effectively detect 
conflicts based on a trajectory prediction, it must be able to very quickly detect when an aircraft 
deviates from the predicted trajectory. Note that the introduction of ADS-B Out for surveillance 
data will provide much more frequent track updates than the current radar surveillance, and will 
enable must faster detection of trajectory nonconformance. Further, trajectory nonconformance 
will be detected as early as possible using downlinked aircraft intent. 

In the MBT environment, it is expected that improved trajectory predictions will support 
longer look ahead times on reliable conflict detection. This, in turn, will support more strategic 
conflict detection and resolution approaches that could be carried out by what today is the D- 
side controller. 
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5.5. Evaluate Amendment Requests 


One reason that reroutes are so time-consuming and difficult in the current environment is 
that there are several manual steps involved in receiving and evaluating flight operator reroute 
requests. In a scenario like the SAA becoming available, each reroute request (for en route 
flights) must be received by a controller via voice, manually entered into the controller 
automation, and evaluated by the automation and the controller. Only a controller working in the 
affected ARTCC can process the reroute. This concentrates the workload associated with 
processing requests on a few controllers, creating a bottleneck that can lead to the controllers 
not accepting any reroute requests at all because they do not have time to process them. 

In an MBT environment, the flight operator can request the reroute at any time, allowing 
many of the reroute requests to be processed before the aircraft enters the affected ARTCC. 
The dispatcher sends these requests directly to the traffic management automation, which can 
evaluate the requested trajectory against known constraints. In many cases, the traffic 
management automation will be able to approve the requested route. Where necessary, the 
traffic management automation will request review by a traffic management specialist. The 
automation will need to have parameters indicating when to request traffic management 
evaluation, and which facility or facilities — e.g., which ARTCC or the ATCSCC — should do the 
evaluation [5]. 

Note that use of the TOS as discussed above would imply that the traffic management 
automation periodically evaluates the TOS for each flight — even in the absence of a CTOP — to 
determine if a different trajectory in the TOS is acceptable and preferred. 


5.6. Evaluate Clearance 


When a clearance is received by the flight deck, it must be evaluated to ensure that the 
aircraft can safely execute it before it can be accepted. In the current environment, the pilot 
takes on the bulk of the work associated with receiving a clearance by voice, writing it down, 
reading it back to the controller, and manually loading it into the FMS for evaluation (or 
evaluating the aircraft's ability to execute the route in autopilot). The ability to receive clearances 
via data link and auto-load them into the FMS will reduce the pilot’s work associated with 
receiving and evaluating a clearance, but the primary responsibility will remain with the pilot. 

In addition, in the MBT environment the controller automation is expected to provide conflict 
resolution advisories. The controller is expected to evaluate such an advisory before providing it 
to the pilot. 

However, the mix of aircraft capabilities in the near term is expected to be so broad that it 
will be infeasible to expect controllers to have the necessary knowledge to quickly determine 
whether a given aircraft has a certain set of capabilities. Thus, the controller automation must 
compare clearances prepared for each aircraft with the aircraft's capabilities. For example, an 
aircraft that can receive clearances via Data Comm and auto-load them will be able to receive 
more complex clearances than an aircraft that cannot auto-load a clearance. 


5.7. Plan Conflict Resolution Clearance 


Note that the function “Plan conflict resolution clearance” is allocated primarily to the 
controller, but also to the pilot, in the current environment. This is because when time permits, 
many controllers will provide pilots two alternative conflict resolutions from which to choose. It is 
noted that this is a desirable feature of the current environment to retain in the MBT 
environment. However, the current development arc of advanced conflict resolution and data 
exchange tools, including CPDLC and automated conflict resolution advisories, does not seem 
to consider this alternative. In order to support this feature, the CPDLC message set must be 
expanded. 
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There was a consensus among the cognitive walkthrough’s controller and pilot participants 
that providing the option is a desirable goal for MBT. The pilot has access to information about 
the aircraft capabilities that is not available to the controller. For example, the controller may 
instruct the aircraft to climb due to traffic but the aircraft may not be able to climb. In other 
cases, the pilot may prefer the climb over a lateral path solution to a conflict. Providing the 
option was considered more efficient than the controller providing a clearance, the pilot rejecting 
it because the aircraft is unable to execute it, and the controller providing an updated clearance. 

In the MBT environment, the controller will retain primary responsibility for planning the 
conflict resolution advisory. But the controller will have significantly more automation support, 
with the automation providing resolution advisories as discussed elsewhere. 


5.7.1 Cross-Sector Coordination 


An important aspect of the earlier detection of conflicts expected in MBT is that conflicts are 
likely to be detected before the conflict aircraft are operating within the sector where the conflict 
occurs (unless sectors are expanded from their current design). Thus, it is important to 
determine not only that the controller is responsible for planning the conflict resolution 
clearance, but which controller. Figure 2 illustrates the situation where two aircraft are predicted 
to conflict in a sector that is downstream for both aircraft (from [6]). 


2 
Downstream 


Figure 2: Inter-sector Conflict (from [6]) 


Previous research into this question has provided different recommendations depending on 
the purpose of the research. Green and Leiden [6] suggested that the upstream controller team, 
(i.e., the controller team responsible for the sector where the aircraft is operating at the time the 
conflict is detected) should be responsible for resolving the conflict and delivering that resolution 
to the aircraft. This was chiefly to minimize coordination requirements and relieve workload in 
the downstream sector, which was expected to be busier. 

Other work has suggested that the conflict be resolved by a new role, the Multi-Sector 
Planner (MSP) [7]. The MSP would not be a controller, and therefore would not have direct 
communication with the aircraft, and so the MSP would create a conflict resolution plan and 
provide the clearance to the controller currently responsible for the aircraft to deliver. 

A similar alternative to the MSP role is a reorganization of traffic management specialists 
such that they take on a greater role in flow management and conflict resolution across sector 
and facility boundaries. These traffic management specialists could be oriented toward flows 
and conflicts needing resolution rather than strict geographical boundaries like they are today. 
They could be located in field facility ARTCCs or at the ATCSCC. They would be responsible for 
responding to conflicts and driving the negotiation to update each aircraft’s trajectory constraints 
accordingly. 

These previous results beg the question: What should the controller of, for example, Sector 
1 in Figure 2 be responsible for? Should that controller be monitoring the predicted 
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(downstream) trajectories of the aircraft currently operating in Sector 1 to identify and resolve 
conflicts between those aircraft and other aircraft currently operating in yet other sectors (e.g., 
Sector 4 in Figure A-2)? If this is the case, coordination and/or procedures would be required 
between the Sector 1 and Sector 4 controllers to ensure that the conflict between Aircraft A and 
Aircraft B is resolved. 

Green and Leiden [6] suggested that automation determine which controller should be 
notified of the conflict, with the other controller notified only after a period of time with inaction. 
On the other hand, the MSP would be responsible for adjusting both aircraft trajectories as 
needed to resolve the conflict and providing the clearances for both aircraft to the respective 
sector controllers to deliver to the aircraft [7]. 

Alternatively, the MSP, a traffic management specialist, or some other position could use 
Data Comm to uplink the clearance directly to the aircraft if certain conditions are met [5]. The 
chief consideration in these conditions is that the change in either aircraft’s trajectory is 
sufficiently downstream from its current position that it is outside any tactical controller’s 
planning horizon. 

However, MBT cognitive walkthrough participants preferred an approach by which the 
Sector 2 controller be responsible for identifying and resolving the conflict, and then providing 
the clearances for Aircraft A and B to the Sector 1 and 4 controllers, respectively, to deliver to 
the aircraft. Note that Green and Leiden [6] rejected this approach because of the coordination 
required among the sector controllers and the potential that the downstream sector’s clearance 
(e.g., Sector 2) would be made obsolete by an action taken by the upstream controller (e.g., 
Sector 1). The latter concern would be lessened by the MBT approach to resolving conflicts by 
modifying the assigned trajectory, in which the amended assigned trajectory is provided to all 
relevant stakeholders, and automation supports participants in avoiding trajectory amendments 
that introduce new problems. 

It must be noted, however, that the cognitive walkthrough participants’ preferred approach, 
in which the downstream controller is responsible for resolving the conflict, aligns best with the 
current environment in which conflicts are detected and resolved within a single sector (i.e., the 
conflict shown in Figure A-2 would not be acted upon until one or both aircraft had entered the 
control of Sector 2). The cognitive walkthrough participants may have been biased by their 
experience with the current environment, characterized by poor trajectory predictability such that 
it is not effective to act early on a detected conflict. 

MBT allocates this responsibility to the upstream controller, at least in the near term. The 
controller is responsible for solving problems related to the trajectories of the aircraft under 
his/her control. It is desirable to resolve conflicts as early as practical, and with improved 
trajectory predictability they can be resolved much earlier than today. If the controller 
responsible for the aircraft at the time the conflict is detected is responsible for resolving the 
conflict, then the downstream controller will take responsibility for an aircraft after the conflict 
has been resolved and likely will never know the aircraft had been involved in a conflict. The 
conflict resolution clearance must conform to all existing constraints on the assigned trajectory if 
at all possible, minimizing the chance that the conflict resolution will introduce any new 
problems. 

It is reasonable to expect that as conflict detection horizons increase, controllers will find 
themselves increasingly working on trajectory issues outside their sector. At such a point, it is 
desirable to reconsider controller responsibilities, and possibly shift to an approach like the 
geographically-neutral traffic management specialist discussed above. 

Further research is required to determine which upstream controller should be responsible 
for resolving the conflict in all cases, including situations like that illustrated in Figure A-2 in 
which the conflicting aircraft are currently operating in two separate upstream sectors. This is a 
key requirement for the conflict detection automation. Automation might use a prioritization 
scheme to identify the controller to notify of the conflict that includes factors such as controller 
workload and whether the conflict resolution advisory modifies the trajectory of one or both 
aircraft. The prioritization scheme also should consider the goals of MBT, including: 
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e Resolve problems as early as practical to minimize the magnitude of trajectory changes 

and allow time for negotiation 

e Allow fully equipped aircraft to remain on their trajectories without controller intervention 

to the extent possible (best equipped, best served) 

e Keep aircraft on closed trajectories to the extent possible 

e Evaluate the downstream effects of a proposed trajectory amendment to avoid 

introducing new conflicts 

e Manage controller workload 

ANSP ground automation already has aircraft performance information, but these detailed 
models do not support controllers in identifying conflict resolution clearances. In an MBT 
environment, the assigned trajectory object will contain more detailed information about aircraft 
capabilities, and advanced data exchange capabilities could update this information for the 
controller automation in real-time that would be used in constructing and/or trial planning a 
conflict resolution. 

A key aspect of planning the conflict resolution clearance is determining the best way to 
“translate” the controller's plan into a clearance that is appropriate for a given aircraft’s 
capabilities. The expected mixture of aircraft equipage associated with receiving clearances (via 
Data Link or voice), auto-loading a Data Link clearance into the FMS, executing clearances 
(e.g., RTA, interval management, Dynamic RNP, execution of 4DT clearances), etc., will require 
more knowledge about specific aircraft capabilities than what is available to the ATC system 
today. Further, this level of Knowledge about specific aircraft is likely too much for controllers to 
process in developing a conflict resolution plan. Thus, it is important that controller automation 
utilize information about aircraft capabilities to support controllers in constructing a conflict 
resolution plan and associated clearance. 

Some additional automation capabilities would support the controller in effectively and 
efficiently resolving conflicts. For example, the controller automation should automatically 
update the proposed clearance if the controller amends the resolution advisory. 

Also, there was consensus among controllers participating in the cognitive walkthrough that 
a coordination countdown timer should ensure that all controllers know how much time is 
available to approve the amendment before the solution is no longer valid. One controller noted, 
however, that a long lead time on the coordination countdown timer will require that the 
automation keep up with any changes made to other aircraft trajectories that might affect the 
validity of the solution. Note that this latter requirement is valid for all of the functions related to 
selecting, negotiating, and implementing a trajectory amendment. 


5.8. Execute Step Climb 


In one of the conflict detection and resolution use cases, the controller provides the aircraft 
an interim altitude to resolve the conflict. A key part of the interim altitude solution is the aircraft 
executing the climb after leveling off or descending to avoid traffic. In the current environment, 
the controller tells the aircraft to descend (or stop its climb), and then when it is time for the 
aircraft to climb again the controller instructs the aircraft to climb. However, a closed 4DT should 
include the step climb. An important question is who is responsible for ensuring that the aircraft 
executes the step climb. In the current environment, the responsibility is clearly the controller's. 
But in the MBT environment, it is not clear whether the controller or the pilot should be 
responsible for prompting execution of the step climb. 

No FMS currently is designed to execute the vertical profile automatically the way they 
execute the lateral profile (except in specific phases of flight), and the standards for future FMS 
do not envision such behavior either. Cognitive walkthrough participants expressed that 
expecting the aircraft to execute the vertical profile in the same way it executes the lateral profile 
would entail “quite a learning curve” for pilots and “a big change” for controllers. One pilot who 
participated in the cognitive walkthrough cautioned that he would prefer that ATC tell him to 
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climb “when | need to do it.” Unless there is an upfront reminder, he said it is “probable” that he 
will not remember to do it. In fact, this is in line with anecdotal evidence that controllers are 
discouraged from providing conditional clearances because pilots frequently forget to execute 
them. It may be true that responsibility for the step climb should remain with the controller 
except for aircraft that can automatically execute the vertical profile. 

The cognitive walkthrough participants did provide suggestions for useful ways to construct 
the clearance such that the aircraft could execute it. Namely, they suggested the use of 
clearances such as: 

e “REACH [altitude] BY [time]” or “REACH [altitude] BY [fix]” 

e “CROSS [fix] AT [altitude]” 

e “AT [fix] CLIMB TO FL [altitude]” 

e “CROSS [fix]/[distance] AT [altitude]/S” 

These are clearances that can be used today, although the first two are the only ones that 
are typically used. The third is rarely used, and the fourth cannot currently be loaded in an FMS. 

It would be a philosophy shift for aviation, but part of the vision of MBT is that aircraft 
operate along their assigned trajectories without intervention from controllers. Of course, the 
premise of this use case is that controller intervention was required to maintain separation. 
However, controllers typically prefer to provide one clearance to resolve a conflict and move on 
to their next task. Once the capability is available for the controller to resolve the conflict by 
amending the aircraft's assigned trajectory, this capability should support minimizing controller 
intervention and workload to the extent possible. Thus, the automation should support the 
controller providing the interim altitude clearance in one step using any of the clearances 
discussed above. Similarly, it should support the pilot in executing that clearance in minimal 
steps; the pilot should be able to auto-load the clearance and the aircraft follow the vertical 
profile indicated in the clearance. 


5.9. Plan Path Stretch 


In today’s environment, the controller manually determines whether a path stretch is needed 
to meet a trajectory constraint (e.g., MIT spacing or metering delay) and plans the path stretch 
based on knowledge of the effects of winds aloft on earlier aircraft ground speeds. In an MBT 
environment, controller or traffic management automation could plan the path stretch and 
provide a recommendation to the user. Whether the path stretch should be a controller or traffic 
management responsibility would depend on the amount of delay that needed to be absorbed. If 
the path stretch spans multiple sectors, it may be a traffic management responsibility to support 
cross-sector coordination. However, given the discussion in Section 5.7 about cross-sector 
coordination of conflict resolution actions, it may be sufficient for the controller first notified of the 
time constraint to plan the path stretch and have automation that supports coordinating the 
planned path stretch with other affected controllers. This is a potential subject for future 
research — namely, the situations in which it is more appropriate for such a plan to be a traffic 
management versus controller responsibility and the performance characteristics of each 
approach. 

If a path stretch is required to achieve the trajectory constraint (i.e., speed reduction is 
insufficient), controller automation is expected to support controllers in planning a path stretch to 
achieve the goal. However, the controller will be required to be in the loop in planning the path 
stretch, especially in the near term. Cognitive walkthrough participants noted that in order to be 
helpful in designing the path stretch, the automation must have accurate wind models and good 
predictions of the effect of wind on the aircraft’s capabilities. 

Note that in the near term, controllers may not be comfortable with automation-proposed 
path stretch solutions. This is an expected near- or mid-term TBFM controller tools capability. 
One controller participant in the cognitive walkthrough said, “I would rather tell the automation 
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what to do than have it suggest something,” and suggested tools to support controllers in easily 
defining a path stretch instead. 


5.10. Plan Speed Adjustment 


If time constraints are applied to the aircraft trajectories for flow management, the preferred 
approach is to uplink an RTA to the aircraft. Thus, the pilot will be primarily responsible for 
selecting the speed schedule to meet the time constraint. The pilot also will be responsible for 
using aircraft automation for managing speed if interval management were used to meet a 
spacing goal. However, if an aircraft is not equipped to perform these functions with sufficient 
precision, the controller would provide a speed advisory and could use automation to identify 
the appropriate speed (note that GIM-S is capable of this today in support of metering 
constraints). 

Note that a speed constraint for metering can be provided by GIM-S in today’s environment, 
but since the flight plan assigned speed is not changed, the trajectory is still open. Implementing 
metering by applying a time constraint to the assigned trajectory, and sharing that time 
constraint with all relevant participants and automation systems, effectively closes the trajectory 
since the time at the meter fix will be Known throughout the system. 


5.11. Monitor Conformance with the Assigned Trajectory 


In the current environment, pilots are primarily responsible for operating the aircraft in 
conformance with the clearances provided by the controller, including the flight plan, and 
notifying the controller of the intent to deviate from this shared plan. Some operations already 
require aircraft to be equipped to monitor conformance with various aspects of a trajectory. For 
example, RNP requires conformance monitoring with a lateral path, and time of arrival control 
(TOAC) requires monitoring conformance with an arrival time at a waypoint. In both cases, the 
pilot is notified when the aircraft is UNABLE. Similarly, vertical navigation (VNAV) provides the 
pilot information consistent with the spirit of conformance monitoring. In such cases, the pilot is 
responsible for either adjusting operation of the aircraft to return to conformance, or coordinating 
an alternative with the controller. 

Controller automation also monitors the aircraft trajectory for conformance with the flight 
plan in order to support sector controllers in coordinating the handoff. It is not concerned with 
downstream ETAs. In this use case, the downstream ETAs are not constraints on the assigned 
trajectory; rather, they are estimates used by the various automation systems for planning 
purposes. In a previous focus group with pilots, the concept of onboard versus ground 
responsibility for conformance monitoring was explored [8]. Participants in that activity stated 
that they would prefer to be notified first of nonconformance, before the controller, allowing them 
the opportunity to correct the nonconformance and coordinate with the dispatcher as needed. 
They noted that downlinked aircraft intent would include the nonconforming trajectory, and so 
there would not be much time between the pilot notification and the controller and dispatcher 
notification. 

This (limited) feedback from pilots is consistent with TBO concepts in which the 4DT is 
considered a contract between the ANSP and the flight operator, and consistent with a goal of 
MBT that aircraft follow the assigned trajectory without controller intervention. Thus, the pilot is 
given primary responsibility for trajectory conformance, including conformance monitoring. This 
also gives the pilot primary responsibility for resolving trajectory nonconformance, as discussed 
in the next section. 

However, a key aspect of this use case is the stronger than predicted headwind. In sucha 
case, not only does the aircraft have a low-resolution wind forecast, but that forecast is 
incorrect. Ground automation, on the other hand, uses surveillance data to monitor the aircraft 
ground speed and has higher resolution winds than the aircraft. In this case, the ground 
automation may more quickly detect the trajectory nonconformance, particularly as it uses 
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trajectory predictions to monitor demand at the downstream constrained resource. Further, the 
controller is ultimately responsible for separation management, which requires close monitoring 
of trajectory conformance. 

Thus, it is clear that a ground automation conformance monitoring capability is required, in 
addition to onboard automation, to support controllers and traffic managers in achieving MBT. 
However, additional research is necessary to determine whether this should be a standalone 
capability or if it should be incorporated into one or more other automation systems (e.g., traffic 
management and/or controller automation). 


5.12. Resolve Trajectory Nonconformance 


In the current environment, detecting and resolving trajectory nonconformance is not as 
important as it is expected to be in an MBT environment, particularly in the time dimension. To 
the extent that a controller identifies trajectory nonconformance as an issue, the controller will 
provide instructions to the aircraft that will return it to its flight plan route. In the process, the 
controller may ask the pilot to explain the situation. 

Managing aircraft by trajectories requires that there is a consistent view across all 
participants and automation systems of the aircraft's planned trajectory. When nonconformance 
is detected, the pilot will have the most information about the reason for the nonconformance in 
most cases. A significant delay due to a poor wind forecast such as in this use case is an 
exception. In such a case, the dispatcher and controller will likely have access to better 
information about the winds. 

Since the pilot is expected to have the most information about the reason for the 
nonconformance, as well as the most information about what the aircraft can do to resolve the 
nonconformance, the pilot is allocated primary responsibility for this function in the MBT 
environment. However, the dispatcher in many cases has access to relevant information such 
as all of the published NAS data reflecting the ground system trajectory predictions, the aircraft 
data, and the flight operator preferences to determine how to resolve the nonconformance. 
Thus, the dispatcher is allocated secondary responsibility. Note that flight operators typically 
have procedures in place for pilot-dispatcher coordination when route amendments are needed, 
and it is expected that each flight operator organization will identify situations in which the pilot 
or the dispatcher has primary responsibility for this function. The key for MBT is that automation 
to support trajectory conformance monitoring, trajectory amendment, and negotiation must be 
able to accommodate either pilot or dispatcher participation in this function. 

However, not all aircraft are supported by a dispatcher. In such cases, the pilot will need to 
resolve the nonconformance, possibly by explaining the situation to ATC. If the pilot is unable to 
resolve the nonconformance, the controller may need to intervene to ensure that the aircraft and 
ground automation have all of the appropriate data to ensure consistent trajectory predictions. 


5.13. Request Trajectory Amendment 


In the current environment, flight plan amendment requests for en route flights typically 
come from the pilot, although the dispatcher may coordinate reroutes in cases such as dynamic 
weather that is significantly downstream from the aircraft's current location. In the MBT 
environment it is expected that there will be some distance from the Trajectory Change Point 
(TCP) at which the aircraft will be considered too close to the TCP for the trajectory amendment 
to be coordinated by the dispatcher (e.g., an aircraft already operating within the controller’s 
planning horizon). In such cases, the pilot will continue to request the trajectory amendment and 
not the dispatcher. Such requests will be downlinked to the controller. 

However, for flights that are farther from the TCP, the dispatcher will be able to request the 
trajectory amendment directly from the traffic management automation, which is expected to be 
capable of evaluating most requests and agreeing to the requested change, rejecting the 
request, and/or negotiating with the flight operator until an amended assigned trajectory is 
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agreed upon. In fact, it is expected that Flight Operations Center (FOC) automation will be 
capable of requesting an amended trajectory and even negotiating with the traffic management 
automation on the flight operator’s behalf. 

Note that the TOS associated with CTOP and flight operator and traffic management 
automation to manage TOS submission and evaluation are current-day examples of such 
capabilities. In the near- to mid-term MBT environment, it is expected that flight operators will be 
capable of maintaining an up to date TOS. Even when no CTOP is in place, the traffic 
management automation would evaluate the TOS to determine whether the current set of 
airspace and trajectory constraints render a different trajectory on file to be preferred by the 
flight operator. 


5.14. Plan Weather Deviation 


In the current environment, pilots request deviation parameters from the controller (e.g., 20 
degrees left of course), and the controller will provide the pilot as much discretion as possible to 
safely operate the aircraft. Anecdotally, controllers often note that their displays only show radar 
returns, and so they only see weather systems on their displays if there is precipitation. 
Meanwhile, pilots can see weather systems out the window of the aircraft and can identify cloud 
formations (e.g., the “anvil” of a thunderstorm) that indicate treacherous airspace. However, 
controllers (and pilots) also note that the flight deck radar displays are limited in scope, and so 
pilots requesting a deviation may not see a system behind the one they are trying to avoid. 

Thus, pilots are primarily responsible for planning a weather deviation path in the current 
environment, and controllers support pilots to the extent that they can in planning safe and 
efficient weather deviation routes. This is not expected to change in the MBT environment, since 
pilots are ultimately responsible for safely operating the aircraft and their out the window view of 
the weather, coupled with their knowledge of how to handle the aircraft, are given significant 
weight (even though the pilot’s assessment of the weather may be incorrect). While it is 
expected that both pilots and controllers will have access to better weather information in the 
future, including advanced aircraft automation that supports identifying a weather avoidance 
path, it is likely that the pilot and controller will still need to collaborate to identify the best 
weather deviation route. 

Defining the best approach to maintaining a closed clearance while the aircraft deviates 
around the weather is a major challenge for MBT. In addition to the heading used today, two 
alternatives are presented in the weather deviation use case: 1) the pilot requests an offset that 
essentially increases the lateral tolerance on the trajectory; and 2) the pilot uses advanced 
onboard automation to request a specific deviation path. In all alternatives, the pilot is 
responsible for planning the deviation path. Two additional alternatives were considered in 
which the controller and the dispatcher, respectively, used a ground based automation 
capability to propose a weather avoidance route. 

Two of the pilot cognitive walkthrough participants noted that it may be difficult for pilots to 
identify the lateral distance offset shown in Figure 3, although this is already the procedure in 
oceanic airspace (and one of the two pilots routinely operated in oceanic airspace). The two 
pilots said that they are reasonably confident that their initially requested heading will allow them 
to “skirt” the weather they see out the window, but they hesitated to commit to an offset until 
they were able to see what might be behind the weather they could see on the radar. 


22 


Figure 3: Weather Deviation Offset Clearance (Modified From [9]) 


An advantage of the lateral offset is that it defines a volume of airspace to be protected for 
the deviating aircraft and thus preserves the spirit of performance-based navigation. However, 
this approach would create significant downstream uncertainty because the FMS would not 
have a reliable route it could use to estimate downstream ETAs. It is hard to say whether such a 
trajectory is really closed since the time dimension is uncertain. 

All of the cognitive walkthrough participants expressed enthusiasm for the variation in which 
the pilot requested a specific weather deviation route using advanced aircraft automation. 
Participant statements included: 

e Pilot: “Seems like the pilot would have more certainty than today.” 

e Controller: “At least there is structure there so now | know and may be able to run 

aircraft closer to him... Uncertainty is bad for controllers.” 

However, there still would be potentially significant uncertainty associated with the 
trajectory. As with the lateral offset, the pilot would need to estimate a specific route based on 
the available (imperfect) weather information. If the estimated route is too close to the actual 
weather, the pilot will need to request an alternate; thus, the trajectory may be predictable but 
unstable. On the other hand, if the pilot requests a trajectory that is more conservative than 
necessary the system benefits from a potentially more stable, closed trajectory, but the aircraft 
is not operating as efficiently as it could. 

The ground-based alternatives suffer the same predictability, stability, and efficiency issues, 
but without the pilot’s out the window view. Note that controllers today sometimes provide 
weather avoidance routes, typically to maintain uniformity within a flow of aircraft, but they may 
be more conservative in selecting such routes than necessary. Other concepts have been 
designed to support dispatchers and even traffic managers in selecting weather avoidance 
routes [10], but the focus has been on reducing the flight time/distance associated with weather 
reroute TMIs as opposed to identifying a route around weather that has not already been 
anticipated to affect a given aircraft. Ground based alternatives are preferred when the need to 
deviate can be predicted well in advance, typically before the weather is visible on the flight 
deck radar. 

Yet another alternative is for the pilot to propose the deviation trajectory — either a lateral 
offset or complete trajectory — and for the other participants to support negotiation such that the 
amended assigned trajectory takes into account both the pilot’s assessment of the out the 
window view and the more comprehensive radar data available on the ground. 


5.15. Plan Reroute 


In the current environment, airborne reroutes require a traffic management specialist to 
manually enter the reroute. In addition to other efforts to increase automation support for 
managing airborne reroutes, MBT can make use of the TOS and traffic management 
automation that is already designed to manage changes to the preferred trajectory option after 
departure. A key part of this is FOC automation that keeps the TOS up to date throughout the 
life of the flight, adding responsibility to the dispatcher for ensuring that the TOS is appropriately 
maintained. In the event that a reroute is required — or a more efficient route comes available — 
the traffic management automation can quickly identify a trajectory in the TOS and offer it to the 
flight operator. 
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5.16. Negotiate Trajectory 


Roles and responsibilities associated with trajectory negotiation have been explored in the 
NextGen Trajectory Negotiation (NTN) ConOps [5]. That work proposed that trajectory 
negotiation be handled by FOC and traffic management automation to the extent possible to 
minimize workload for all participants and to ensure that negotiation takes place with a system- 
oriented view. The expectation is that trajectories negotiated by dispatchers and traffic 
managers would be less likely to create new downstream problems than trajectories negotiated 
by controllers and pilots. 

CTOP has been implemented since the NTN ConOps was written, and provides a 
negotiation approach that is in line with the NTN ConOps. Dispatchers are responsible for 
providing the TOS to the traffic management automation, which selects the flight operator 
preferred TOS option for a given situation and offers it to the FOC, which evaluates and then re- 
files the newly awarded trajectory. In the future environment, more of the negotiation is 
expected to be handled by automation, and it is not expected that the dispatcher/ATC 
coordinator will need to re-file the awarded TOS option. 

One cognitive walkthrough participant suggested considering the use of a TOS at all times, 
even in the absence of a CTOP program. Negotiation via the TOS would work the same way 
whether there was an active CTOP or not. This implies that the allocation of responsibility for 
trajectory negotiation would be consistent with that proposed for this use case in many other 
use cases as well. 


5.17. Maintain and Update Trajectory Options Set (TOS) 


In the current (or near-future) environment, flight operators have automation to support 
dispatchers in maintaining and resubmitting the TOS as conditions and preferences change. 

While the pilot does not submit TOS options, the pilot does coordinate preferences and 
options with the dispatcher. The pilot should be in the decision-making loop and therefore is 
included as a participant with responsibility for this function. 

The allocation of responsibility ostensibly does not change in the MBT environment. 
However, the expanded access to information and automation capabilities on the flight deck 
may increase the role of the pilot. It is conceivable that advanced aircraft automation can 
support TOS maintenance. 


6. Conclusions and Recommendations 


The key changes in allocation of responsibilities between the current environment and the 
MBT environment are associated with increased automation capability and increased flexibility 
for different participants to take on certain tasks in different situations. For example, increased 
data exchange infrastructure creates the possibility of flexibility in delivering information — 
including clearances — to the aircraft, such as from traffic management automation in addition to 
controller automation. 

In many cases, the primary assignment of responsibility is not expected to change in the 
MBT environment, but the way in which the participant is expected to perform the function 
and/or the automation support provided is expected to change. For example, the use of 
trajectory constraints to manage airspace constraints associated with MBT will require a 
different approach to managing airspace constraints. In particular, use of MIT would require a 
way to “translate” the in-trail separation requirement into specific trajectory constraints. This 
could be accomplished using flight deck interval management for appropriately equipped 
aircraft, or it could be accomplished by applying crossing time constraints to individual 
trajectories reflecting the required separation. The latter approach implies that the airspace 
constraint could (and possibly should) be managed using time-based metering instead. 


24 


The trade study identified some automation requirements beyond what is included in the 
current arc of development. For example, when time permits in the current environment, many 
controllers will provide pilots two alternative conflict resolutions from which to choose. The 
cognitive walkthrough participants noted that this is a desirable feature of the current 
environment to retain in the MBT environment. However, the current development arc of 
advanced conflict resolution and data exchange tools, including CPDLC and automated conflict 
resolution advisories, does not seem to consider this alternative. In order to support this feature, 
the CPDLC message set must be expanded. 

Similarly, MBT envisions sufficiently capable aircraft being able to fly their assigned 
trajectories without intervention from the controller. Aircraft are capable of doing this in the 
lateral dimension, but no FMS currently is designed to execute the vertical profile automatically 
the way they execute the lateral profile (except in specific phases of flight), and the standards 
for future FMS do not envision such behavior either. Automatic execution of the vertical profile 
would be quite a change in philosophy for pilots and controllers and may not be within the MBT 
vision for the near term. However, it is a desirable goal for the end state so that aircraft are 
operating on closed 4DTs more frequently. 
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7. Acronyms 


Acronym Definition 

ABRR Airborne Reroute 

ADS-B Automatic Dependent Surveillance-Broadcast 
ADS-C Automatic Dependent Surveillance-Contract 
AFP Airspace Flow Program 

ANSP Air Navigation Service Provider 

ARTCC Air Route Traffic Control Center 

ATC Air Traffic Control 

ATCSCC Air Traffic Control System Command Center 
ATM Air Traffic Management 

ATN Aeronautical Telecommunications Network 
ATOP Advanced Technologies & Oceanic Procedures 
ATSP Air Traffic Service Provider 

CDM Collaborative Decision Making 

CPDLC Controller-Pilot Data Link Communications 
CTOP Collaborative Trajectory Options Program 
EDCT Expect Departure Clearance Time 

EFB Electronic Flight Bag 

EPP Extended Projected Profile 

ERAM En Route Automation Modernization 

FMS Flight Management System 

FOC Flight Operations Center 

FRD Fix/Radial/Distance 

FSM Flight Schedule Monitor 

GDP Ground Delay Program 

ICAO International Civil Aviation Organization 

IFC In-Flight Connectivity 

MAP Monitor Alert Parameter 

MBT Management by Trajectory 

MIT Miles in Trail 

NAS National Airspace System 

NCR NAS Common Reference 

NOTAM Notices to Airmen 

NTML National Traffic Management Log 

NTN NextGen Trajectory Negotiation 

RNP Required Navigation Performance 

RTA Required Time of Arrival 

RTP Required Time Performance 

RTCA Radio Technical Commission for Aeronautics 
SAA Special Activity Airspace 

SWIM System Wide Information Management 
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TAP Traffic Aware Planner 

TASAR Traffic Aware Strategic Aircrew Request 
TBFM Time Based Flow Management 
TBO Trajectory Based Operations 
TCP Trajectory Change Point 

TFM Traffic Flow Management 
TFMData Traffic Flow Management Data 
TFMS Traffic Flow Management System 
TFR Temporary Flight Restriction 

TMI Traffic Management Initiative 
TMU Traffic Management Unit 

TOD Top of Descent 

TRACON Terminal Radar Control 

TSD Traffic Situation Display 
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Appendix A: Management by Trajectory Use Cases Analysis 


There were eight main use cases used to identify the key Management by Trajectory (MBT) 
functions for which the distribution of roles and responsibilities should be evaluated: 

e Controller issues a vector for traffic 
Controller issues an interim altitude for traffic 
Controller issues vectors for miles in trail (MIT) sequencing 
Controller issues vectors for time based metering 
Pilot requests deviation for weather 
Dispatcher requests delayed arrival for gate management 
Dispatcher requests reroute for Special Activity Airspace (SAA) restriction 
Use of Collaborative Trajectory Options Program (CTOP) TMI to manage multiple 
constraints 

In each use case, the present day procedures and automation support capabilities were 
summarized and then an approach to resolving the associated issues in an MBT environment 
was proposed. 

This section describes the use cases — present day procedures and in an MBT environment, 
the key MBT functions identified, and the participant assigned responsibility for the function in 
the MBT environment. 


Controller Issues Vector for Traffic 


In this case, the controller resolves a conflict after receiving a conflict alert. 


Use Case Steps 
Present Day Procedures and Automation 


1. URET conflict probe alerts of pending separation issue between AAL262 & AAL1516, 12 
minutes before loss of separation. 

2. The controller completes several trial plans. The first is to climb AAL262 to FL350; 

however, that reveals a conflict with AAL700 (DFW-EWR). 

The next trial plan shows that FL310 has no conflicts. 

The controller issues a vector for a 15-degree right turn. 

The pilot turns, and the open trajectory begins (i.e., neither the flight crew nor the 

automation knows when the controller will turn the AC back). 

6. Once clear of traffic, 6 minutes later, the controller re-clears the aircraft direct RMG and 
updates the route in ERAM. The pilot executes the reroute. 
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Managed in an MBT Environment 


1. Strategic: conflict probe alerts of pending separation issue between AAL262 & AAL1516, 
20 minutes before loss of separation. Conflict probe provides an automated resolution 
advisory with the reroute solution. 

2. Controller evaluates and approves the resolution advisory and provides the reroute to 
the flight deck. 


“Strategic conflict probe” here is used to distinguish this conflict alerting capability from the current 
ERAM conflict probe, which acts on a very limited look ahead (6-8 minutes). This strategic conflict probe 
could be URET or similar future capability. 
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3. Flight deck reviews, accepts, and executes the reroute. 
4. Assigned trajectory is amended and shared. 


AAL262 
EELS 
757 404 _ 


Figure A-1: Lateral path conflict resolution solution 


Note that there are several use case variations associated with this use case in an MBT 
environment that are discussed below. 


Variations on the Conflict Detection Horizon 


Improved trajectory predictability in the MBT environment will support an even longer conflict 
detection horizon than indicated in the use case, on the order of 30 minutes or more. At this 
horizon, it is likely that adding a time constraint to one or more of the aircraft trajectories would 
resolve the conflict without requiring them to otherwise change their trajectories. The controller 
uplinks an RTA to either or both aircraft. The pilot evaluates, accepts, and executes the RTA, 
and the aircraft automation adjusts the aircraft speed accordingly. This case requires the 
controller automation to know both aircrafts’ time performance capabilities to identify time 
constraints that provide sufficient separation and minimize the speed adjustments required. 

On the other hand, some unforeseen trajectory change limiting trajectory predictability could 
delay conflict detection until the resolution requires immediate execution (e.g., an aircraft 
encountered turbulence or some malfunction that required it to change altitude). Immediate 
execution of the conflict resolution would prohibit the use of CPDLC to coordinate the trajectory 
amendment. In this case, the controller provides the clearance by voice and ensures that the 
clearance is captured in the automation such as by accepting the automated resolution advisory 
or entering the clearance provided to the aircraft. 

Similarly, a lateral route change may require more time to execute than a speed or altitude 
change, and so a shorter conflict detection horizon may preclude the lateral route change 
illustrated in this use case. 


“Equipped” and “Unequipped” Aircraft Capabilities 


In this use case, an “equipped” aircraft is capable of both receiving a clearance via CPDLC 
and auto-loading it into the FMS. Such aircraft are able to receive complex clearances because 
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there is minimal opportunity for human error in the process of entering the new route into the 
FMS. 

An “unequipped” aircraft is not CPDLC-equipped and must receive clearances via voice. 
Such clearances must be simple enough to deliver that the flight crew can quickly write it down, 
read it back, and manually enter it into the FMS for evaluation. 

Note that even in the near term many aircraft are expected to be equipped to receive 
clearances via CPDLC, but will not support auto-loading clearances into the FMS. It be easier to 
keep these aircraft on closed trajectories than voice-only aircraft because there can always be a 
digital copy of a clearance provided by CPDLC. However, aircraft that do not support FMS auto- 
load will not be able to receive complex clearances or clearances involving latitude/longitude 
because they still must be entered into the FMS manually. Thus, the clearance provided to the 
aircraft will not be significantly different from that provided to a voice-only aircraft. 


Use Case Assumptions 


The proposed approach to managing the conflict in an MBT environment incorporates 
several assumptions about the operational environment. These are presented here with some 
discussion as to their effect on the use case in an MBT environment. 


Earlier Conflict Detection 


Improved trajectory prediction supported by MBT and other TBO concepts allows conflicts to be 
detected sooner than in the present day. In the use case, the example of a 20-minute look 
ahead was used, but the look ahead time for conflict detection will depend on several factors, 
including just how good the system is at predicting trajectories. 

The 20-minute look ahead was selected for this use case because that is currently the 
typical look ahead used for URET.? Since the use case was presented to retired controllers and 
traffic managers at the cognitive walkthrough who would be familiar with URET, the research 
team wanted the look ahead time to seem plausible to them. 

However, the cognitive walkthrough participants stressed that they do not use URET to 
detect conflicts for several reasons. First and foremost, they strive to perform conflict detection 
and resolution manually specifically to avoid dependence on automation. They indicated that 
depending on automation to alert them to conflicts would indicate that they were not capable of 
managing the traffic scenario efficiently enough to consistently provide conflict solutions that 
would not introduce a second conflict. 

Secondly, the current conflict detection and alerting tools provided to controllers - URET 
and ERAM conflict probe — use different data and algorithms and therefore produce different 
results. URET provides longer look ahead times than ERAM conflict probe, but it does not have 
all the necessary data to accurately predict trajectories at those look ahead times. In large part, 
this is due to the use of open trajectories. Cognitive walkthrough participants gave examples 
such as departures having their climbs stopped to avoid conflicts with crossing traffic. The 
controllers working those flows of traffic know that the aircraft will have their climbs resumed to 
meet the agreed handoff altitude, but the automation does not have access to that information. 

On the other hand, ERAM conflict probe uses track data to make assumptions about aircraft 
behavior in the next 6-8 minutes. When aircraft are in “free track”, i.e., when the automation has 
detected that the aircraft is operating on an open trajectory, ERAM makes assumptions about 
when the aircraft will rejoin its flight plan route and the trajectory it will use to get there. 


2 The look ahead time is a facility assigned parameter (20-60 minutes), but most facilities set it at 20 
(the minimum) because it becomes less accurate the further out in time it probes. 
32 


A key goal of the MBT concept is to keep aircraft operating on closed trajectories as much 
as possible. This will increase predictability, which is required to support earlier conflict 
detection. As the conflict detection horizon (and traffic volume) increases, controllers will need 
to increase their use of automation to support conflict detection and resolution. Increasing the 
conflict detection horizon such that conflicts are managed by amending trajectory constraints 
before the conflicting aircraft enter the ATC sector where the conflict occurs has implications for 
the distribution of responsibility among controllers. The D-side controller that today assists the 
R-side controller is more likely to have the information needed to reliably detect conflicts and 
can take action to coordinate resolving such conflicts before the aircraft enter the sector. This 
requires inter-sector coordination, as discussed below. 


Controller Automation Provides Conflict Resolution Advisories 


Automated conflict resolution advisories are expected to be available in ERAM starting in 
2019. Thus, it is expected that in the end state MBT operational environment, these will be not 
only available but routinely used by controllers. 

The routine use of automated conflict resolution advisories would drastically reduce the 
number of aircraft operating on open trajectories due to vectors for traffic. However, the MBT 
concept does not depend on this capability to maintain closed trajectories. During the cognitive 
walkthrough, the discussion of this use case started with the premise that the controller 
automation would suggest a conflict resolution, but the discussion quickly moved to ideas for 
approaches to supporting controllers in providing conflict resolutions in a way that was easy and 
would maintain a closed clearance. 

However, even if the controller developed his/her own conflict resolution, the controller 
automation would prepare the clearance for the controller to deliver to the aircraft. This would 
allow a single controller action to resolve the conflict using a closed trajectory. 


Use Case Functions, Allocation, and Automation Requirements 


The functions identified in the use case are summarized in Table A-1. Table A-1 also 
provides the allocation of the function in the current environment and in the MBT environment. 
Where multiple participants are indicated for a given function, the primary participant is listed 
first. For example, in the current environment, controllers are primarily responsible for conflict 
detection with automation support. However, in the MBT environment, it is expected that 
controller automation will have a more significant role in conflict detection and resolution. 

Also, where only the human participant is noted as responsible for a function, the human 
participant likely has automation to support performing that function. However, the automation is 
not listed because it is intended as an aid to the human participant that is responsible for 
carrying out the function. 


Table A-1: Vectors for Traffic Use Case Functions and Allocation 


mr Ularer ace} (Oli ac-al@Ali(elersliteyal ila MAN Keler-tatelal 
Detect conflict Controller Controller 
Plan conflict Controller Controller (Aircraft Sector) 


resolution clearance Pilot Pilot 
Deliver conflict Controller Controller (Aircraft Sector) 
resolution clearance 


3 FAA, "NAS Target Top Level Systems Requirement Document (Target RD), Version 4.0," Federal 
Aviation Administration, Washington, DC, 2014. 
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Evaluate conflict Pilot Controller 
resolution clearance Pilot 


Execute conflict Pilot Pilot 
resolution clearance 
Amend flight plan N/A Controller 


Notes on Proposed MBT Allocation and Automation Requirements 


The following paragraphs provide reasoning behind the proposed MBT allocation of some of 
the functions in Table A-1. This explanation focuses on the aspects of those items that differ 
between the current environment and the MBT environment. 


Detect Conflict 


Controllers will retain responsibility for conflict detection in the MBT environment, but MBT 
will allow the automation they use to be much more reliable than it is today. Cognitive 
walkthrough controller participants stressed that in the current environment they are not likely to 
use their strategic conflict detection capability for several reasons. Critically, the strategic tool 
does not have access to all of the data it needs to produce an accurate trajectory prediction. For 
example, if a climbing aircraft has been leveled off by the controller in the previous sector, the 
controller receiving the strategic conflict alert knows that the previous sector controller will 
continue the aircraft’s climb before handing it off. However, the strategic conflict probe does not 
know the aircraft will continue its climb. MBT conflict detection automation will require access to 
the updated assigned trajectory and the ability to share trajectory changes across sectors. The 
core of the MBT concept, i.e., applying constraints to the assigned trajectory to effect change in 
the trajectory, will support the controller automation in meeting these requirements. 

The controller participants also noted that if controller automation is to effectively detect 
conflicts based on a trajectory prediction, it must be able to very quickly detect when an aircraft 
deviates from the predicted trajectory. Note that the introduction of ADS-B Out for surveillance 
data will provide much more frequent track updates than the current radar surveillance, and will 
enable must faster detection of trajectory nonconformance. Further, trajectory nonconformance 
will be detected as early as possible using downlinked aircraft intent. 


Plan Conflict Resolution Clearance 


Note that the function “Plan conflict resolution clearance’ is allocated primarily to the 
controller, but also to the pilot, in the current environment. This is because when time permits, 
many controllers will provide pilots two alternative conflict resolutions from which to choose. It is 
noted that this is a desirable feature of the current environment to retain in the MBT 
environment. However, the current development arc of advanced conflict resolution and data 
exchange tools, including CPDLC and automated conflict resolution advisories, does not seem 
to consider this alternative. In order to support this feature, the CPDLC message set must be 
expanded. 

There was a consensus among the controller and pilot participants that providing the option 
is a desirable goal for MBT. The pilot has access to information about the aircraft capabilities 
that is not available to the controller. For example, the controller may instruct the aircraft to 
climb due to traffic but the aircraft may not be able to climb. In other cases, the pilot may prefer 
the climb over a lateral path solution to a conflict. Providing the option was considered more 
efficient than the controller providing a clearance, the pilot rejecting it because the aircraft is 
unable to execute it, and the controller providing an updated clearance. 

In the MBT environment, the controller will retain primary responsibility for planning the 
conflict resolution advisory. But the controller will have significantly more automation support, 
with the automation providing resolution advisories as discussed elsewhere. 
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An important aspect of the earlier detection of conflicts expected in MBT is that conflicts are 
likely to be detected before the conflict aircraft are operating within the sector where the conflict 
occurs (unless sectors are expanded from their current design). Thus, it is important to 
determine not only that the controller is responsible for planning the conflict resolution 
clearance, but which controller. Figure A-2 illustrates the situation where two aircraft are 
predicted to conflict in a sector that is downstream for both aircraft.* 


2 


Downstream 


Figure A-2: Inter-sector Conflict® 


Previous research into this question has provided different recommendations depending on 
the purpose of the research. Green and Leiden® suggested that the upstream controller team, 
i.e., the controller team responsible for the sector where the aircraft is operating at the time the 
conflict is detected, should be responsible for resolving the conflict and delivering that resolution 
to the aircraft. This was chiefly to minimize coordination requirements and relieve workload in 
the downstream sector, which was expected to be busier. 

Other work has suggested that the conflict be resolved by a new role, the Multi-Sector 
Planner (MSP).’ The MSP would not be a controller, and therefore would not have direct 
communication with the aircraft, and so the MSP would create a conflict resolution plan and 
provide the clearance to the controller currently responsible for the aircraft to deliver. 

These previous results beg the question: What should the controller of, for example, Sector 
1 in Figure A-2 be responsible for? Should that controller be monitoring the predicted 
(downstream) trajectories of the aircraft currently operating in Sector 1 to identify and resolve 
conflicts between those aircraft and other aircraft currently operating in yet other sectors (e.g., 
Sector 4 in Figure A-2)? If this is the case, coordination and/or procedures would be required 
between the Sector 1 and Sector 4 controllers to ensure that the conflict between Aircraft A and 
Aircraft B is resolved. 


4 Figure from S. Green and K. Leiden, "A Trajectory Orientation Approach to En Route Strategic 
Planning," in 3rd USA/Europe Air Traffic Management R&D Seminar, 2000. 


5 |bid. 
6 Ibid. 


7N. Smith, T. Prevot, A. Kessell, J. Homola, H. Lee, J. Mercer, C. Brasil, M. Mainini and P. Lee, "A 
human-in-the-loop evaluation of multi-sector planning in mixed equipage airspace (MSP III)," NASA Ames 
Research Center, Moffett Field, CA, 2011. 
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Green and Leiden® suggested that automation determine which controller should be notified 
of the conflict, with the other controller notified only after a period of time with inaction. On the 
other hand, the MSP would be responsible for adjusting both aircraft trajectories as needed to 
resolve the conflict and providing the clearances for both aircraft to the respective sector 
controllers to deliver to the aircraft.° 

Alternatively, the MSP, a traffic manager, or some other position could use Data Comm to 
uplink the clearance directly to the aircraft if certain conditions are met.?° The chief 
consideration in these conditions is that the change in either aircraft’s trajectory is sufficiently 
downstream from its current position that it is outside any tactical controller's planning horizon. 

However, MBT cognitive walkthrough participants preferred an approach by which the 
Sector 2 controller be responsible for identifying and resolving the conflict, and then providing 
the clearances for Aircraft A and B to the Sector 1 and 4 controllers, respectively, to deliver to 
the aircraft. Note that Green and Leiden rejected this approach because of the coordination 
required among the sector controllers and the potential that the downstream sector’s clearance 
(e.g., Sector 2) would be made obsolete by an action taken by the upstream controller (e.g., 
Sector 1). The latter concern would be lessened by the MBT approach to resolving conflicts by 
modifying the assigned trajectory, in which the amended assigned trajectory is provided to all 
relevant stakeholders, and automation supports participants in avoiding trajectory amendments 
that introduce new problems. 

It must be noted, however, that the cognitive walkthrough participants’ preferred approach, 
in which the downstream controller is responsible for resolving the conflict, aligns best with the 
current environment in which conflicts are detected and resolved within a single sector (i.e., the 
conflict shown in Figure A-2 would not be acted upon until one or both aircraft had entered the 
control of Sector 2). The cognitive walkthrough participants may have been biased by their 
experience with the current environment, characterized by poor trajectory predictability such that 
it is not effective to act early on a detected conflict. 

MBT allocates this responsibility to the upstream controller. The controller is responsible for 
solving problems related to the trajectories of the aircraft under his/her control. It is desirable to 
resolve conflicts as early as practical, and with improved trajectory predictability they can be 
resolved much earlier than today. If the controller responsible for the aircraft at the time the 
conflict is detected is responsible for resolving the conflict, then the downstream controller will 
take responsibility for an aircraft after the conflict has been resolved and likely will never know 
the aircraft had been involved in a conflict. The conflict resolution clearance must conform to all 
existing constraints on the assigned trajectory if at all possible, minimizing the chance that the 
conflict resolution will introduce any new problems. 

Further research is required to determine which upstream controller should be responsible 
for resolving the conflict in all cases, including situations like that illustrated in Figure A-2 in 
which the conflicting aircraft are currently operating in two separate upstream sectors. This is a 
key requirement for the conflict detection automation. Automation might use a prioritization 
scheme to identify the controller to notify of the conflict that includes factors such as controller 
workload and whether the conflict resolution advisory modifies the trajectory of one or both 
aircraft. The prioritization scheme also should consider the goals of MBT, including: 


8 Green and Leiden, 2000. 
9 Smith, et al., 2011. 


10 FAA, "NextGen Trajectory Negotiation Concept of Operations," Federal Aviation Administration, 
Washington, DC, 2014. 


11 Green and Leiden, 2000. 
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e Resolve problems as early as practical to minimize the magnitude of trajectory changes 

and allow time for negotiation 

e Allow fully equipped aircraft to remain on their trajectories without controller intervention 

to the extent possible (best equipped, best served) 

e Keep aircraft on closed trajectories to the extent possible 

e Evaluate the downstream effects of a proposed trajectory amendment to avoid 

introducing new conflicts 

e Manage controller workload 

ANSP ground automation already has aircraft performance information, but these detailed 
models do not support controllers in identifying conflict resolution clearances. In an MBT 
environment, the assigned trajectory object will contain more detailed information about aircraft 
capabilities, and advanced data exchange capabilities could update this information for the 
controller automation in real-time that would be used in constructing and/or trial planning a 
conflict resolution. 

A key aspect of planning the conflict resolution clearance is determining the best way to 
“translate” the controller's plan into a clearance that is appropriate for a given aircraft’s 
capabilities. The expected mixture of aircraft equipage associated with receiving clearances (via 
Data Link or voice), auto-loading a Data Link clearance into the FMS, executing clearances 
(e.g., RTA, interval management, Dynamic RNP, execution of 4DT clearances), etc., will require 
more knowledge about specific aircraft capabilities than what is available to the ATC system 
today. Further, this level of Knowledge about specific aircraft is likely too much for controllers to 
process in developing a conflict resolution plan. Thus, it is important that controller automation 
utilize information about aircraft capabilities to support controllers in constructing a conflict 
resolution plan and associated clearance. 

Some additional automation capabilities would support the controller in effectively and 
efficiently resolving conflicts. For example, the controller automation should automatically 
update the proposed clearance if the controller amends the resolution advisory. 

Also, there was consensus among controllers participating in the cognitive walkthrough that 
a coordination countdown timer should ensure that all controllers know how much time is 
available to approve the amendment before the solution is no longer valid. One controller noted, 
however, that a long lead time on the coordination countdown timer will require that the 
automation keep up with any changes made to other aircraft trajectories that might affect the 
validity of the solution. Note that this latter requirement is valid for all of the functions related to 
selecting, negotiating, and implementing a trajectory amendment. 


Deliver Conflict Resolution Clearance 


The controller is expected to be responsible for delivering the clearance to the aircraft in 
conflict avoidance situations. However, a key difference in the MBT environment is the 
expectation that the controller will deliver a closed clearance as much as possible. To support 
this, it is desirable to make the process as consistent as possible for the controller, regardless of 
aircraft capabilities. As noted above, the automation is expected to automatically build a 
clearance appropriate for the aircraft based on the automated conflict resolution advisory and 
controller modifications of the advisory. For clearances that must be delivered by voice, the 
controller automation needs to make it as easy as possible for the controller to provide the 
clearance to the ground automation. 


Evaluate Conflict Resolution Clearance 


In the current environment, the pilot evaluates a clearance, including a conflict resolution 
clearance, before executing it to ensure it is safe for the aircraft. This will also be required in an 
MBT environment. 

In addition, in the MBT environment the controller automation is expected to provide conflict 
resolution advisories. The controller is expected to evaluate such an advisory before providing it 
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to the pilot. The controller is listed first in Table A-1 only because the controller will be the first 
person to evaluate the clearance and not because the controller's responsibility is considered 
greater than that of the pilot's. 


Amend Flight Plan/Assigned Trajectory 


In the current environment, the aircraft's flight plan would not be amended to account for the 
conflict resolution clearance. In the MBT environment, the assigned trajectory will be amended 
to account for all clearances provided to the aircraft. In this use case, the controller is 
responsible for ensuring that the assigned trajectory is amended. There are some important 
considerations for automation support for this function. 

It is important to note that adding responsibility to the controller for entering all clearances 
provided by voice into the automation has consequences. First, controllers may be more likely 
to accept the automated solution to avoid manually entering information into the automation, 
which requires that the automation provides adequate solutions (and makes it desirable for 
automation to consistently provide solutions that are as good as or better than those the 
controller would propose). More consistent use of automated conflict resolution advisories may 
decrease controllers’ skill at detecting and resolving conflicts manually, which could present a 
safety issue if controllers are expected to be the safety net in the case of automation failure. 

If a controller has to enter a clearance manually into the automation, it is important that not 
only is the automation designed to make that easy, but having the information in the automation 
also must provide a benefit to controllers. Research has shown that when people are expected 
to enter data into automation to support others with no benefit to themselves, it is not likely that 
they will do so.‘ Thus, to support closed clearances, the controller automation should be 
designed with the following goals in mind: 

e Amend assigned trajectory without explicit controller action to the extent possible 

e Facilitate easy assigned trajectory amendment in cases where controller must enter 

information manually. 


Controller Issues Interim Altitude for Traffic 


This is a variation of the use case in which the controller issues an interim altitude rather 
than a lateral path solution to resolve the conflict. 


Use Case Steps 
Present Day Procedures and Automation 


1. URET conflict probe alerts of pending separation issue between AAL262 & AAL1516, 12 
minutes before loss of separation. 


2. The controller completes several trial plans; the first is to climb AAL262 to FL350, 
however that reveals a conflict with AAL700 (DFW-EWR). The next trial plan shows 
FL310 has no conflicts. 


The controller verbally clears AAL262 to descend to FL310. 
4. Pilot descends to FL310. 


22 J, Grudin, "Why CSCW applications fail: Problems in the design and evaluation of organizational 
interfaces," in Proceedings of the 1988 ACM Conference on Computer-Supported Cooperative Work, 
New York, 1988. 
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5. Once clear of traffic the controller clears aircraft to FL330 and removes the interim 
altitude. 


6. The pilot climbs to FL330. 
Note that trajectory probing in ERAM remained at FL330 during the entire event. 
Managed in an MBT Environment 


1. Strategic conflict probe alerts of pending separation issue between AAL262 & AAL1516, 
20 minutes before loss of separation. Conflict probe provides an automated resolution 
advisory with an interim altitude solution. 


2. Controller evaluates the resolution advisory and provides the interim altitude to the flight 
deck. 


3. Flight deck reviews, accepts, and executes the interim altitude. 
4. Assigned trajectory is amended and shared. 


Updating the assigned 4D trajectory for the flight allows ERAM to probe along the interim 
altitude. 
Similar to the previous use case, there are several variations associated with this use case 
in an MBT environment: 
e Variations on the conflict detection horizon affecting available resolution options and 
ability to deliver the clearance via CPDLC 
e Aircraft data exchange equipage 


Use Case Assumptions 


The proposed approach to managing the conflict in an MBT environment incorporates the 
same assumptions as the previous use case (Controller Issues a Vector for Traffic). They are 
listed here for convenience; refer to the discussion associated with the previous use case for 
more information. 

e Earlier conflict detection 

e Controller automation provides conflict resolution advisories and prepares the clearance 

e Equipped aircraft can receive clearances via CPDLC and auto-load them into the FMS. 

Non-equipped aircraft receive clearances via voice. 


Use Case Functions and Allocation 


The functions identified in the use case are summarized in Table A-2. Table A-2 also 
provides the allocation of the function in the current environment and in the MBT environment. 


Table A-2: Interim Altitude Use Case Functions and Allocation 


srel ated aie) a} forUlaaclal@Alicexersuiceya MBT Allocation 
Detect conflict Controller Controller 
Plan conflict resolution Controller Controller 
clearance Pilot 
Deliver conflict resolution Controller Controller 
clearance 
Evaluate conflict resolution Pilot Controller 
clearance Pilot 
Amend flight plan N/A Controller 
Execute step climb Controller Pilot 
Controller 


39 


Notes on Proposed MBT Allocation 


The following paragraphs provide reasoning behind the proposed MBT allocation of some of 
the functions in Table A-2. Functions discussed previously are not repeated here unless the 
consideration of responsibility assignment was expanded through evaluation of this use case. 


Executing Step Climb 


A key part of the interim altitude solution is the aircraft executing the climb after leveling off 
or descending to avoid traffic. In the current environment, the controller tells the aircraft to 
descend (or stop its climb), and then when it is time for the aircraft to climb again the controller 
instructs the aircraft to climb. However, a closed 4DT should include the step climb. An 
important question is who is responsible for ensuring that the aircraft executes the step climb. In 
the current environment, the responsibility is clearly the controller’s. But in the MBT 
environment, it is not clear whether the controller or the pilot should be responsible for 
prompting execution of the step climb. 

No FMS currently is designed to execute the vertical profile automatically the way they 
execute the lateral profile (except in specific phases of flight), and the standards for future FMS 
do not envision such behavior either. Cognitive walkthrough participants expressed that 
expecting the aircraft to execute the vertical profile in the same way it executes the lateral profile 
would entail “quite a learning curve” for pilots and “a big change” for controllers. One pilot who 
participated in the cognitive walkthrough cautioned that he would prefer that ATC tell him to 
climb “when | need to do it.” Unless there is an upfront reminder, he said it is “probable” that he 
won't remember to do it. In fact, this is in line with anecdotal evidence that controllers are 
discouraged from providing conditional clearances because pilots frequently forget to execute 
them. It may be true that responsibility for the step climb should remain with the controller 
except for aircraft that can automatically execute the vertical profile. 

The cognitive walkthrough participants did provide suggestions for useful ways to construct 
the clearance such that the aircraft could execute it. Namely, they suggested the use of 
clearances such as: 

e “REACH [altitude] BY [time]” or “REACH [altitude] BY [fix]” 

e “CROSS [fix] AT [altitude]” 

e “AT [fix] CLIMB TO FL [altitude]” 

e “CROSS [fix]/[distance] AT [altitude]/S” 

These are clearances that can be used today, although the first two are the only ones that 
are typically used. The third is rarely used, and the fourth cannot currently be loaded in an FMS. 

It would be a philosophy shift for aviation, but part of the vision of MBT is that aircraft 
operate along their assigned trajectories without intervention from controllers. Of course, the 
premise of this use case is that controller intervention was required to maintain separation. 
However, controllers typically prefer to provide one clearance to resolve a conflict and move on 
to their next task. Once the capability is available for the controller to resolve the conflict by 
amending the aircraft's assigned trajectory, this capability should support minimizing controller 
intervention and workload to the extent possible. Thus, the automation should support the 
controller providing the interim altitude clearance in one step using any of the clearances 
discussed above. Similarly, it should support the pilot in executing that clearance in minimal 
steps; the pilot should be able to auto-load the clearance and the aircraft follow the vertical 
profile indicated in the clearance. 


Controller Issues Vectors for MIT Sequencing 


In this use case, due to a low AAR and excessive demand at EWR, ZNY has passed back a 
20 MIT restriction to ZOB for all EWR arrivals. ZOB passes the entire 20 MIT back to ZID. The 
ZID controller issues reduced speed and a turn/path stretch to achieve the required spacing. 
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Note that in the far term, time-based metering is expected to be used for this scenario in 
place of MIT. However, it will likely take some time to phase out use of MIT. 


Use Case Steps 


Present Day Procedures and Automation 


1. 


ZID TMU posts the 20 MIT RSTN on their ESIS board and coordinates with their 
sectors/areas 


The ZID62 controller identifies two EWR arrivals (AAL1516 & AAL1700) that need to be 
sequenced. Taking upper level winds into account, the controller turns AAL1700 30 
degrees left to a heading of 360 (an open clearance). AAL1700 is also asked to reduce 
speed to Mach .76. 


The pilot reduces speed and turns to a 360 heading (open trajectory begins) 


After 5 minutes on that heading, the controller clears AAL1700 direct ROD at Mach .77 
(its original speed) 


The pilot turns back on course to ROD and resumes normal speed 


The controller enters the reroute in ERAM, closing the trajectory, and hands the two 
EWR arrivals off to the next sector perfectly spaced at 20 MIT 


Managed in an MBT Environment 


1. 
2. 


ZID TMU provides the 20 MIT RSTN to the affected sectors/areas 


The ZID62 controller identifies two EWR arrivals (AAL1516 & AAL1700) that need to be 
sequenced. The controller identifies a path stretch for AAL1700. AAL1700 is also 
provided a Required Time of Arrival (RTA) at ROD that achieves the spacing goal. 


The pilot evaluates, accepts, and executes the reroute and the RTA. The trajectory is 
updated in ERAM. 


When AAL1700 crosses ROD the controller provides the aircraft an interval 
management clearance to maintain 20 miles of spacing behind AAL1516 


The controller hands the two EWR arrivals off to the next sector such that they are using 
interval management to maintain 20 MIT 


Use Case Assumptions 


The use case relies on one of the same assumptions as the previous use cases; namely, it 
uses the same definitions of equipped and unequipped aircraft. 
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In addition, the use case assumes that controller automation provides a function allowing 
the controller to draw a path stretch that “snaps” to geographical locations appropriate for the 
aircraft. The geographical location might be lat/lon if the aircraft is equipped (i.e., the flight crew 
can auto-load the clearance). Otherwise, some FMS can accept named fixes not already in 
flight plan and others require heading/range from flight plan fixes (See Figure A-3). Still other 
FMS can take a more sophisticated S-turn defined as 2 fix radius transitions. 


~ 1 


\ 
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Figure A-3: Example path stretch using automatically selected, named waypoints 


Use Case Functions and Allocation 


The functions identified in the use case are summarized in Table A-3. Table A-3 also 
provides the allocation of the function in the current environment and in the MBT environment. 


Table A-3: Vectors for Sequencing Use Case Functions and Allocation 


Function Current Allocation MBT Allocation 

Apply MIT restriction to ARTCC/TRACON Traffic ARTCC/TRACON Traffic 

flow Management Specialist Management Specialist 

Identify aircraft subject to Controller ARTCC/TRACON Traffic 

MIT Management Specialist 

Communicate MIT ARTCC/TRACON Traffic ARTCC/TRACON Traffic 

restriction to controllers Management Specialist Management Specialist 
Area Supervisor Area Supervisor 

Add constraint to achieve Controller ARTCC/TRACON Traffic 

MIT to affected aircraft Management Specialist 


13 FAA, "Dynamic Required Navigation Performance Preliminary Concept of Operations," Federal 
Aviation Administration, Washington, DC, 2014. 
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Controller 

Identify aircraft to be Controller ARTCC/TRACON Traffic 

sequenced Management Specialist 
Controller 

Plan speed reduction Controller Pilot 
Controller 

Plan path stretch Controller ARTCC/TRACON Traffic 
Management Specialist 
Controller 

Deliver clearance Controller Controller 
ARTCC Traffic Management 
Specialist 

Evaluate clearance Pilot Controller 
Pilot 

Execute clearance Pilot Pilot 

Amend flight plan N/A Controller 


Notes on Proposed MBT Allocation 


The following paragraphs provide reasoning behind the proposed MBT allocation of some of 
the functions in Table A-3. Functions discussed in previous sections are not repeated here 
unless the consideration of responsibility assignment was expanded through evaluation of this 
use case. Note that the use case specified ARTCC traffic management, but TRACON traffic 
management also makes use of MIT and MBT should account for that. 


Apply MIT Restriction to Flow 


The decision by traffic management to apply an MIT restriction to the EWR traffic is outside 
the scope of MBT. In fact, in the long-term MBT environment, it is expected that spacing will be 
created using time-based metering and not MIT. However, given the present-day prevalence of 
MIT, MBT must be able to support a near term environment in which MIT is used to manage 
spacing for traffic flows. The role of MBT is to provide a mechanism for “translating” the MIT 
restriction into constraints on individual aircraft trajectories, and the act of applying constraints to 
individual aircraft assigned trajectories associated with the MIT restriction is the responsibility of 
traffic management. In particular, traffic management specialists must select appropriate 
parameters for the traffic management automation to use to identify the affected aircraft, 
compute the appropriate trajectory constraints, and propose the assigned trajectory amendment 
to the trajectory negotiation mechanism. Note that traffic management automation already 
supports these functions for Collaborative Decision Making (CDM) programs and time-based 
metering (except for supporting negotiation). However, current automation provides limited 
support for these functions when MIT is used. 


Identify Aircraft Subject to MIT Constraint 


This function is the act of identifying the aircraft affected by the MIT NAS constraint. In the 
current environment, the traffic management specialist posts the MIT constraint to displays 
available to the controllers, and the controllers must identify the specific aircraft under their 
responsibility that are subject to the constraint. 

In the MBT environment, a reference to the MIT constraint will be automatically applied to 
the affected aircraft assigned trajectories when the traffic management specialist implements 
the MIT constraint. Thus, the traffic management specialist is responsible for ensuring that the 
traffic management automation appropriately identifies the affected aircraft. Traffic management 
automation should support this just as today’s traffic management automation identifies aircraft 
subject to a GDP or AFP. 
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Communicate MIT Restriction to Controllers 


This function is expected to be fully automated in the MBT environment. Currently, traffic 
managers manually enter information to be displayed in control Areas, and controllers are 
required to remain aware of the set of flow requirements affecting the aircraft they work. 

Further, controllers are currently responsible for manually identifying affected aircraft and 
achieving the required spacing between them. In the MBT environment, this can be 
accomplished through trajectory modifications. While controllers may prefer to know about the 
restriction for their situation awareness regarding traffic flows, the critical function is for 
controller automation to notify controllers (and/or traffic managers) of aircraft whose assigned 
trajectories need to be amended to achieve the spacing requirement. 


Add Constraint to Achieve MIT to Affected Aircraft 


This function is the act of applying the trajectory constraints to the specific aircraft 
trajectories to achieve the MIT requirement. 

There are multiple different individual aircraft trajectory constraints that can be applied to 
achieve the desired spacing. For example, aircraft can be provided crossing time constraints 
that would provide 20 MIT between pairs of aircraft on the same flow, or appropriately equipped 
aircraft could maintain the necessary spacing using interval management. In this use case a 
third alternative was proposed, in which automation recommended a speed reduction and/or 
path stretch; this was specifically in order to support a near term environment and capabilities 
already expected for controller automation. 

The selection of which constraint(s) to apply is outside the scope of MBT, but the role 
primarily responsible for applying the constraint(s) depends on this choice. To promote strategic 
trajectory management to the extent possible, MBT encourages the traffic management 
specialist to select an approach to achieving the traffic management goals that provides flight 
operators the greatest flexibility in selecting a 4DT that meets the constraints while also 
providing traffic management sufficient predictability to ensure that the traffic management goals 
will be met. This involves applying the constraints as early as practical. 

However, the controller will still be required to achieve spacing requirements where they 
have not already been achieved by traffic management functions. MBT will provide the 
controller the ability to select the appropriate constraints to apply to aircraft trajectories to meet 
the spacing requirements without introducing new downstream conflicts. 


Identify Aircraft to be Sequenced 


Ideally, the traffic management automation already has planned a sequence for the aircraft 
and identifies pairs of aircraft that require trajectory amendments in order to achieve the 
sequence before the controller takes responsibility for the aircraft. In such cases, the traffic 
management specialist could apply trajectory amendments to one or more aircraft to achieve 
the sequence and is thus given primary responsibility for identifying the aircraft. This may allow 
aircraft to execute the amended trajectory sooner and therefore more efficiently and/or with 
greater flexibility to negotiate the desired approach to meeting the constraints. 

Although applying the necessary constraints more strategically such as by the traffic 
management specialist is desirable, this use case specifically addresses the situation in which 
the aircraft are handed off to the controller without the necessary spacing. In such cases, the 
controller must take responsibility for identifying the pairs of aircraft to be sequenced and 
achieving the needed spacing. 

Both traffic management and controller automation need to identify pairs of aircraft that 
require trajectory amendments to achieve the spacing requirement. A key open question is a 
precise definition of the handoff of responsibility for this function from the traffic management 
specialist to the controller such that both do not simultaneously attempt to solve the same 
problem. 


44 


Whether it is the controller or the traffic management specialist identifying the affected 
aircraft, automation should support precise calculation of the spacing that will be achieved 
without trajectory amendments, immediate identification of aircraft that require trajectory 
amendments to achieve the required spacing, as well as support for planning the trajectory 
amendments. 


Plan Speed Reduction 


If time constraints are applied to the aircraft trajectories to achieve a speed reduction, the 
preferred approach is to uplink an RTA to the aircraft. Thus, the pilot will be primarily 
responsible for executing the RTA such that aircraft automation can implement the necessary 
speed reduction to meet the spacing goal. The pilot also is responsible for using aircraft 
automation for managing speed if interval management were used to meet the spacing goal. 
However, if an aircraft is not equipped to perform these functions with sufficient precision, the 
controller would provide a speed advisory and could use automation to identify the appropriate 
speed (note that GIM-S is capable of this today in support of metering constraints). 


Plan Path Stretch 


If a path stretch is required to achieve the spacing goal (i.e., speed reduction is insufficient), 
it is desirable for the traffic management specialist to use automation to identify this and apply 
the path stretch as early as practical. Performing this function at the traffic management level 
has multiple benefits, including: 1) the path stretch can more easily cross sectors; 2) the path 
stretch crossing multiple sectors can involve a less severe turn off of course, allowing the 
aircraft to stay closer to its preferred trajectory; and 3) controller workload is reduced, allowing 
the controller to focus on those aircraft that for some reason were unable to achieve spacing 
before the controller takes responsibility for the aircraft. 

If the aircraft enter the controller's responsibility without trajectories that will achieve the 
necessary spacing, the controller is responsible for further amending their trajectories as 
needed. Controller automation is expected to support controllers in planning a path stretch to 
achieve the goal. However, the controller will be required to be in the loop in planning the path 
stretch, especially in the near term. 

Traffic management and controller automation need to support the traffic management 
specialist and controller, respectively, in devising a path stretch to achieve the spacing goal 
when required. The ground automation could provide a path stretch advisory, which would 
suggest a path stretch that would achieve the spacing goal. 

Cognitive walkthrough participants noted that in order to be helpful in designing the path 
stretch, the automation must have accurate wind models and good predictions of the effect of 
wind on the aircraft's capabilities. 

Note that in the near term, controllers may not be comfortable with automation-proposed 
path stretch solutions. This is an expected near- or mid-term TBFM controller tools capability. 
One controller participant in the cognitive walkthrough said, “I would rather tell the automation 
what to do than have it suggest something,” and suggested tools to support controllers in easily 
defining a path stretch instead. Such capabilities might include allowing the controller to click on 
a point on the surveillance display to indicate the point the controller wants the aircraft to “aim 
for’ on the path stretch, and automatically generate a clearance that uses the latitude/longitude 
of that point or a reference to a nearby named waypoint. 


Deliver Clearance 


In the current environment, only the controller can deliver a clearance to an aircraft. 
However, Data Link and other forms of advanced data exchange create the possibility for other 
approaches to delivering clearances. The primary approach to delivering clearances in an MBT 
environment will be delivery from the controller via controller automation (i.e., Data Link). But 
when constraints are applied to trajectories due to traffic management programs, the trajectory 
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amendment could be delivered by the traffic management specialist via traffic management 
automation. Previous research has proposed the following requirements for traffic management 
delivery of a clearance:*4 

e The reroute does not affect the aircraft route or speed in the sector of the controller 
currently responsible for the aircraft. 

e The trajectory change point is at least 2 sectors away and 1 hour of flight time away. 

e The controller currently responsible for the flight needs to have access to information 
about the downstream trajectory change in case the flight crew asks about the new 
clearance. 

e If the ARTCC TMU does not issue the clearance early enough, the clearance is sent to 
the controller to deliver. 

e The aircraft must be within the geographical boundary of the ARTCC TMU delivering the 
clearance and under direct control of one of its sectors. 

e The automation should prevent situations in which both the TMU and the controller in 
charge of the aircraft simultaneously issue a clearance. 

e = The flight crew acknowledgment of the amended clearance should only be received by 
the TMU that issued the clearance. 

Further research is needed to quantify performance associated with traffic management 

delivery of clearances in various scenarios, including application of constraints to aircraft 
trajectories to meet traffic management program goals. 


Evaluate Clearance 


As in the current environment, the pilot has primary responsibility for ensuring that the 
clearance provided to the aircraft is safe and achievable before accepting and executing it. 
However, the controller also is given responsibility for this function, in particular to reflect the 
use of advisories provided by controller automation. 

In the current environment, the controller mentally conceives almost all clearances as part of 
the separation management plan. However, if controller automation provides an advisory, it is 
important that the controller evaluates the recommended clearance before accepting and 
uplinking it to ensure that it achieves separation management and flow management 
requirements. 

In the current environment in which open trajectories are used to provide the speed 
reduction and/or path stretch clearance to the flight deck, pilots typically implement the changes 
in the auto-pilot/MCP rather than in the FMS. As a result, the FMS does not recalculate the 
trajectory and does not provide planning guidance to help the pilot determine whether the 
clearance is within the aircraft's performance envelope. Pilots rely on their knowledge and on 
other aircraft monitoring systems to determine if the clearance is achievable. In the MBT 
environment, the closed clearances provided to the flight deck are expected to be more readily 
loaded into the FMS; thus, aircraft automation will better support pilots in evaluating the 
clearance. 


Controller Issues Vectors for Metering 


In this use case, due to a low AAR and excessive demand causing delays into EWR, ZNY 
initiates adjacent center metering with ZOB, ZID, ZDC, and ZBW. 


4 FAA, "NextGen Trajectory Negotiation Concept of Operations," 2014. 
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Use Case Steps 


Present Day Procedures and Automation 


A 


TBFM builds the schedule at each meter fix and computes a Scheduled Time of Arrival 
(STA) for each flight once it crosses the freeze horizon for that fix. This STA is based on 
the TBFM-computed ETA at the meter fix, which may be off by several minutes. ZID 
TMU coordinates with each area and displays the EWR meter lists on the controller 
radar screens. 


The ZID62 controller’s meter list shows a 1-minute delay for AAL1516 and a 5-minute 
delay for AAL1700. 


The controller reduces AAL1516 from Mach .79 (current speed) to Mach .77. This is an 
open clearance. As part of the controller's metering plan, he/she enters the reduced 
speed in the data block as a memory jogger, but it does not modify the flight plan 
assigned speed. 


For AAL1700 speed control alone will be not be enough to reduce the delay in his 
sector, so the controller turns AAL1700 30 degrees left to a heading of 360 and issues a 
speed reduction to .76 mach. 


The pilots reduce speed and AAL1700 turns to a 360 heading (open trajectory begins for 
AAL1700) 


After the delay countdown timer in the data block reaches one minute, the controller 
clears AAL1700 direct ROD. The pilot turns back on course to ROD 


The controller enters the reroute in ERAM and uses data block coordination on the 
handoff to coordinate both AAL1516 & AAL1700’s speeds. 


Managed in an MBT Environment 


a 


Traffic management automation (e.g., TBFM) uses each affected aircraft's ETA at the 
meter fix to build the schedule at each fix, computing an STA for each flight. Winds are 
uplinked to each equipped aircraft’s FMS and the traffic management automation 
requests an ETA min-max report (or similar) from all appropriately equipped aircraft and 
uses improved trajectory predictions to compute a more accurate ETA than is available 
in the current environment. The traffic management automation adds the STA to each 
flight's assigned 4DT as a time constraint and the assigned trajectory is published. ZID 
TMU coordinates with each area and displays the EWR meter lists on the controller 
radar screens. 


The STAs will be implemented by RTA. The ZID62 controller provides the RTA to 
AAL1516. 


AAL1516 reviews and accepts the RTA. The aircraft slows to Mach .77. The new speed 
is provided to the controller automation. 


Controller automation notifies the ZID62 controller that AAL1700 will require a path 
stretch to meet its STA and recommends a path stretch that will absorb the necessary 
delay. 


The ZID62 controller evaluates and accepts the recommended path stretch, and 
provides the path stretch and RTA to the flight deck of AAL1700. 


The flight crew of AAL1700 evaluates, accepts, and executes the path stretch with RTA. 
The aircraft slows to Mach .76 and executes the path stretch. 
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A variation on this use case is one in which the traffic management automation and traffic 
management specialist develop the path stretch and provide it to the controller for delivery to 
the aircraft. 


4. Traffic management automation notifies the traffic management specialist that AAL1700 
will require a path stretch to meet its STA and recommends a path stretch to absorb the 
necessary delay that crosses sector boundaries. The traffic management specialist 
evaluates the path stretch and provides it to the affected sectors for evaluation. 


5. Each of the affected controllers evaluates and accepts the path stretch solution, and the 
ZID62 controller provides the path stretch and updated RTA to the flight deck of 
AAL1700. 


6. The flight crew of AAL1700 evaluates, accepts, and executes the path stretch with RTA. 
The aircraft slows to Mach .76. 


Use Case Assumptions 


In addition to the assumptions associated with the previously discussed use cases, this use 
case assumes that in an MBT environment any aircraft can receive and control to a Required 
Time of Arrival (RTA). The level of aircraft equipage determines the tolerance associated with 
the RTA; a well-equipped aircraft can meet an RTA within +/- 10 seconds (consistent with the 
RTCA standard), whereas a lesser-equipped aircraft will have a wider tolerance. 

The use case also assumes that in order to support use of RTA to meet the schedule at the 
meter fix, the RTAS are assigned at merge fixes and not necessarily at the meter fixes. For 
example, aircraft that merge into the flow at the Merge Fix shown in Figure A-4 would be 
provided RTAs at the Merge Fix and not at the Meter Fix. Aircraft that do not merge into the flow 
until the Meter Fix would be provided RTAs at the Meter Fix. 


Merge Meter 


Figure A-4: Some Flows Merge Before the Meter Fix 


In addition, the use case assumes that in an MBT environment there is automation support 
for a traffic management specialist building a path stretch, similar to the controller automation 
supporting conflict resolution. 


Use Case Functions and Allocation 


The functions identified in the use case are summarized in Table A-4. Table A-4 also 
provides the allocation of the function in the current environment and in the MBT environment. 
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Table A-4: Vectors for Metering Use Case Functions and Allocation 


Function Current Allocation | MBT Allocation 
Apply adjacent center ARTCC Traffic Management ARTCC Traffic Management 
metering to flow Specialist Specialist 
Coordinate metering ARTCC Traffic Management ARTCC Traffic Management 
program with affected Specialist Specialist 
Areas 
Plan speed reduction Controller Pilot 
Controller 
Plan path stretch Controller Controller 
ARTCC Traffic Management 
Specialist 
Deliver clearance Controller Controller 
ARTCC Traffic Management 
Specialist 
Evaluate clearance Pilot Pilot 
Controller 
Execute clearance Pilot Pilot 
Amend flight plan N/A Controller 


Notes on Proposed MBT Allocation 


The following paragraphs provide reasoning behind the proposed MBT allocation of some of 
the functions in Table A-4. Functions discussed in previous sections are not repeated here 
unless the consideration of responsibility assignment was expanded through evaluation of this 
use case. 


Plan Speed Reduction 


In the current environment, traffic management automation identifies aircraft that are subject 
to metering based on the parameters set by the traffic management specialist and sets an STA 
for the aircraft at the meter fix. This is not expected to change in the MBT environment, except 
that the STAs will be more achievable since they will be based on more accurate trajectory 
predictions. 

The traffic management automation computes the delay the aircraft should absorb in each 
sector to meet the STA. Controller automation notifies the controller by displaying a delay 
countdown timer to the controller for affected flights. The controller is responsible for ensuring 
that the aircraft absorbs the indicated delay before handing it off to the next sector. The STA is 
never applied directly to the aircraft. 

In the MBT environment, the STA will be applied directly to the assigned trajectory and 
available to all stakeholders. Rather than displaying a delay countdown timer to controllers, in 
an MBT environment the traffic management automation will provide the controller the RTA at 
the meter fix to uplink to the aircraft. Alternatively, the traffic management specialist could uplink 
the RTA to the aircraft. 

Since RTA is the method of choice for ensuring the aircraft meets its STA, the pilot is 
primarily responsible for engaging the aircraft automation to plan the speed reduction (i.e., 
selecting appropriate speed(s) to meet the RTA). 

For an aircraft that is not equipped to meet the RTA with sufficient precision, the controller 
can provide a speed advisory. Note GIM-S can support the controller in selecting the reduced 
speed in today’s environment. 


Plan Path Stretch 


In today’s environment, the controller manually determines whether a path stretch is needed 
and plans the path stretch based on knowledge of the effects of winds aloft on earlier aircraft 
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ground speeds. In an MBT environment, controller or traffic management automation could 
provide a path stretch advisory to the user. Whether the path stretch should be a controller or 
traffic management responsibility would depend on the amount of delay that needed to be 
absorbed. If the path stretch spans multiple sectors, it may be a traffic management 
responsibility to support cross-sector coordination. This is a potential subject for future research 
— namely, the situations in which it is more appropriate for such a plan to be a traffic 
management versus controller responsibility and the performance characteristics of each 
approach. 


Pilot Requests Deviation for Weather 


In this use case, a pilot requests a deviation around weather. A key point to this use case is 
that the pilot sees weather out the window that is not visible on the ground automation radar, or 
that looks worse out the window than indicated by the radar display. Otherwise, traffic 
management, ATC, and the dispatcher likely would have already taken action to provide the 
flight a reroute around the weather. Thus, the pilot in this case has the most information about 
the weather and the desired proximity to it. 


Use Case Steps 
Present Day Procedures and Automation 
1. Pilot of AAL262 observes weather ahead and requests deviation left of course 
2. Controller: “Deviation left of course approved, proceed DRCT FERDY when able” 


3. Pilot begins deviating left of course. Once clear of the weather, the pilot advises ATC 
“DRCT FERDY” 


4. Controller acknowledges and updates route line in ERAM 


A variation on this use case is one in which after several minutes off course, AAL262’s data 
block has gone into free track. Prior to handoff to the next sector, the controller needs to update 
the trajectory, done by approximating a point in space (guessing) based on where previous 
aircraft deviated or based on depicted weather. In the current environment, this guess is 
associated with the “worst case” such that the aircraft is very unlikely to pass that point before 
returning to course, but the aircraft is likely to return to course before that point. 


Managed in an MBT Environment 


1. Pilot of AAL262 observes weather ahead and requests a weather deviation. Controller 
advises pilot he/she is cleared to deviate up to 10 miles left of current route (See Figure 
A-5). 


2. Controller increases tolerance on lateral trajectory between the aircraft's current position 
and FERDY, giving the pilot discretion to deviate around the weather. 


3. Increased tolerance on AAL262’s trajectory affects ability to predict downstream 
conformance and conflicts. 
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Figure A-5: Weather Deviation Offset Clearance’ 


Note that the system does not have more information than it has today about the aircraft's 
trajectory while it is deviating. However, it is known that the controller’s and pilot's intent is for 
the aircraft to return to its route by time it crosses FERDY. Adding a time constraint at FERDY 
would seem to close the loop on the deviation clearance, but the aircraft will be unable to 
accurately predict its crossing time at FERDY since it does not know its precise path around the 
weather. Thus, ETAs provided by the aircraft as part of the aircraft intent are not likely to be 
accurate or stable until the aircraft crosses FERDY. In order for downstream trajectory 
predictions to be somewhat accurate, ground automation will need to estimate downstream 
delays, possibly using information about delays experienced by other aircraft that deviated 
around the same weather system. 

In a variation on this use case, the aircraft is equipped with advanced automation that 
supports identifying a weather avoidance path. In this variation, the use case steps are: 


1. Pilot observes weather ahead and uses advanced flight deck automation to generate a 
lateral path around the weather. The automation combines aircraft radar with uplinked 
weather information. The pilot uses the automation generated route and his 
interpretation of the weather situation to evaluate the route. 


Pilot downlinks reroute request to ATC. 


Controller evaluates and approves the weather deviation reroute, and uplinks a 
clearance to the aircraft. 


4. Flight crew loads, evaluates, accepts, and executes the deviation reroute 


The process is repeated, or the conformance bound is increased, if the pilot needs further 
deviation. A key feature of this variation is that the aircraft remains on a closed trajectory 
throughout the weather deviation. However, the predicted trajectory may be unstable as the 
flight crew requests additional deviations. After some number of new trajectory requests, the 
controller or the flight crew may choose to revert to the approach of increasing the tolerance on 
the current trajectory in an attempt to avoid further requests. Note that this approach may be 
required in some regions of airspace, such as those that have not yet had demand reduced to 
account for the weather system. 


Use Case Assumptions 


In addition to the assumptions associated with previous use cases, this use cases 
introduces a “fully equipped” aircraft that has flight deck automation that supports the flight crew 
in identifying a weather deviation route as well as an appropriate data link connection to 
downlink the route request. The fully equipped aircraft also has CPDLC and FMS auto-load. 

New technologies make it possible to provide more information than ever to an EFB. For 
example: 


15 Figure modified from: ICAO, "Global Operational Data Link Document (GOLD), 2nd Edition," 
International Civil Aviation Organization, Montreal, 2013. 
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ADS-B In provides traffic data 
New connections make more data available from the ground (SWIM, weather, etc.) 
Aircraft interface devices (AIDs) extract data from the FMS 
Increased computing power 

Emerging concepts take advantage of these technologies. For example, NASA's Traffic 
Aware Planner (TAP) implements the Traffic Aware System Aircrew Request (TASAR) concept, 
which supports en route re-optimization that considers aircraft capabilities, traffic data, wind, 
weather, etc.6+’. The flight deck automation variation of this use case leverages the 
TASAR/TAP concept. Importantly, TAP generates an optimized flight path that is deconflicted 
for traffic, weather, etc., while focusing on calculating a fuel, time, or combination benefit for the 
flight. 


Use Case Functions and Allocation 


The functions identified in the use case are summarized in Table A-5. Table A-5 also 
provides the allocation of the function in the current environment and in the MBT environment. 


Table A-5: Weather Deviation Use Case Functions and Allocation 


relates aie)a} (orUlaaclal@Alicexercliteya =a PANE Kexersuiteya 
Identify need to deviate Pilot Pilot 
Plan weather deviation Pilot Pilot 
Controller Controller 
Deliver clearance Controller Controller 
Evaluate clearance Pilot Pilot 
Controller 
Execute clearance Pilot Pilot 
Amend flight plan Controller Controller 


Notes on Proposed MBT Allocation 


The following paragraphs provide reasoning behind the proposed MBT allocation of some of 
the functions in Table A-5. Functions discussed in previous sections are not repeated here 
unless the consideration of responsibility assignment was expanded through evaluation of this 
use case. 


Identify Need to Deviate 


In an MBT environment, it is still expected that there will be times when the pilot will have 
better information than any automation — air or ground — about weather in the vicinity of the 
aircraft and decide to deviate. In such situations, the pilot will have the primary responsibility for 
identifying the need to deviate. However, in the MBT environment it is expected that many 
aircraft will have advanced automation that can identify a weather avoidance route. A 
recommended weather avoidance route may prompt the pilot to consider deviating. 


16 J, Henderson, "Traffic Aware Strategic Aircrew Requests (TASAR) Concept of Operations," NASA 
Langley Research Center, Hampton, VA, 2013. 


1” J, M. Maris, M. A. Haynes, D. J. Wing, K. A. Burke, J. Henderson and S. E. Woods, "Traffic Aware 
Planner (TAP) Flight Evaluation," NASA Langley Research Center, Hampton, VA, 2014. 
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Plan Weather Deviation 


In the current environment, pilots request deviation parameters from the controller (e.g., 20 
degrees left of course), and the controller will provide the pilot as much discretion as possible to 
safely operate the aircraft. Anecdotally, controllers often note that their displays only show radar 
returns, and so they only see weather systems on their displays if there is precipitation. 
However, pilots can see weather systems out the window of the aircraft and can identify cloud 
formations (e.g., the “anvil” of a thunderstorm) that indicate treacherous airspace. However, 
controllers (and pilots) also note that the flight deck radar displays are limited in scope, and so 
pilots requesting a deviation may not see a system behind the one they are trying to avoid. 

Thus, in addition to maintaining safe separation between aircraft, controllers support pilots to 
the extent that they can in planning safe and efficient weather deviation routes. This is not 
expected to change in the MBT environment. While it is expected that both pilots and controllers 
will have access to better weather information in the future, including advanced aircraft 
automation that supports identifying a weather avoidance path, it is likely that the pilot and 
controller will still need to collaborate to identify the best weather deviation route. 

Two of the pilot cognitive walkthrough participants noted that it may be difficult for pilots to 
identify the lateral distance offset shown in Figure A-5, although this is already the procedure in 
oceanic airspace (and one of the two pilots routinely operated in oceanic airspace). The two 
pilots said that they are reasonably confident that their initially requested heading will allow them 
to “skirt” the weather they see out the window, but they hesitated to commit to an offset until 
they were able to see what might be behind the weather they could see on the radar. 

All of the cognitive walkthrough participants expressed enthusiasm for the variation in which 
the pilot requested a specific weather deviation route using advanced aircraft automation. 
Participant statements included: 

e Pilot: “Seems like the pilot would have more certainty than today.” 

e Controller: “At least there is structure there so now | know and may be able to run 

aircraft closer to him... Uncertainty is bad for controllers.” 
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Dispatcher Requests Reroute for Special Activity Airspace Restriction 


In this use case, a dispatcher requests a more efficient route for a flight when a Special 
Activity Airspace (SAA) is made available. A large exercise at Volk Field in WI, called Northern 
Lightning, is coordinated between the military and the FAA. This exercise requires the fighter 
training airspace to extend up to FL500 during several busy periods during the day. The event 
affects a busy aviation corridor causing hundreds of reroutes, particularly MSP and ORD 
arrivals/departures. 
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Figure A-6: Example FCA for Northern Lightning Exercise 


Use Case Steps 
Present Day Procedures and Automation 


1. The Air Traffic Control System Command Center (ATCSCC) and local Traffic 
Management Units (TMUs) build Flow Constrained Areas (FCAs) and brief the flight 
operators on all the planning teleconferences (see Figure A-6). Dispatchers file flight 
plans around the airspace for all flights captured in the FCAs. 


2. During the middle of the military exercise the flight operator ATC desk receives an 
ATCSCC advisory notifying that the Northern Lightning airspace has been cancelled for 
the remainder of the day. The ATCSCC opens the Tactical Customer Advocate (TCA) 
position to support flight operators in rerouting flights. 


3. The ATC coordinator disseminates the cancellation notice to the FOC floor and all 
dispatchers begin sending ACARS messages to all affected flights including route 
guidance. 


4. DAL610, en route from SEA to DTW, receives the ACARS message and requests a 
shortcut from the controller working ZLC32. Since the reroute request involves fixes far 
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beyond the next fix in ZMP, the controller instructs the pilot to forward the request on the 
next frequency. 


30 minutes later DAL610 requests the reroute on ZMP’s frequency, which is approved 
and entered into ERAM. 


For some aircraft, the flight operator sends a group of reroute requests to the TCA 
position at the ATCSCC. The TCA is able to amend flight plans, but there is a delay as 
the traffic management specialists working the TCA position manually process each 
flight. 


This same coordination between dispatchers and pilots, then pilots and controllers is 
taking place in dozens of sectors throughout the NAS, as each flight operator tries to 
improve efficiency, reduce delay and save fuel. 


Managed in an MBT Environment 


1. 


The ATCSCC and local TMUs build FCAs and brief the flight operators on all the 
planning teleconferences. The dispatchers file flight plans around the airspace for all 
flights captured in the FCAs. 


During the exercise the flight operator ATC desk receives an ATCSCC advisory that the 
Northern Lightning airspace has been cancelled for the remainder of the day. ANSP 
automation removes that constraint from the assigned trajectory of any flight that 
referenced it. 


Relevant dispatchers receive notifications that identify the flights whose assigned 
trajectories have had the reference to the constraint removed. They begin coordinating 
reroutes for affected flights: 


a. Submit trajectory amendments to the ANSP for flights that are “far enough away” for 
ground-ground negotiation 


b. Uplink proposed trajectory amendments to the flight deck (e.g., via ACARS) to 
request from the controller 


DAL610, en route from SEA to DTW, is “far enough away” (currently in ZLC32). The 
dispatcher submits an amendment request to the ANSP automation with the trajectory 
change point in ZMP. ZMP TMU reviews and approves the amendment request. ZMP 
TMU sends the amendment to ZLC. It passes automated screening to be sent to ZLC32. 
The controller provides the amended clearance to DAL610. 


DAL611, en route from MSP to BOS, is not “far enough away’ (e.g., already in ZMP). 
The dispatcher uplinks an amendment to the flight deck (e.g., via ACARS). The flight 
crew evaluates the amendment and requests it from the controller. The controller 
evaluates and approves the amendment and provides the amended clearance to 
DAL611, executing the reroute in ERAM. 


This same coordination between dispatchers and ANSP automation, dispatchers and 
pilots, then pilots and controllers is taking place in dozens of sectors throughout the 
NAS, as each flight operator tries to improve efficiency, reduce delay and save fuel. 


Note that the approach to managing the constraints, and advanced automation support, 
reduces the need for the TCA position unless there is an issue in the process of negotiating a 
trajectory amendment for a given flight. 

In a variation on this use case, the ZMP TMU sends the amendment to ZLC. ZLC TMU 
personnel and/or automation review the amendment and uplink it directly to the flight deck 
without controller intervention. 
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In a second variation, the ZMP TMU uplinks the amendment directly to the flight deck 
without coordination with ZLC or controller intervention. 

In a third variation, the flight operator maintains an updated Trajectory Options Set (TOS) on 
file with the traffic management automation that includes an optimized trajectory through the 
FCA/SAA. When the SAA is reopened and the FCA is canceled, the traffic management 
automation automatically and immediately identifies the flight operator’s trajectory option as its 
preferred trajectory and offers it to the flight operator. 


Use Case Assumptions 


A key assumption associated with this use case is the use of a capability that allows the 
flight operator to reference the constraint (FCA) being avoided by the assigned 4DT. Since the 
assigned 4DT avoids the constrained area, the FCA constraint will not be directly included in the 
ADT in the same way that a time constraint would be. This is an important part of the constraint 
sharing and constraint management that are fundamental to MBT. 

In addition, it is expected that in an MBT environment, military SAA is integrated into traffic 
management automation such that opening and closing of SAA is immediately and 
automatically communicated to the FAA. Similarly, effective trajectory management requires an 
agile communication/coordination network that has the ability to quickly respond to the opening 
and closing of available airspace. 


Use Case Functions and Allocation 


The functions identified in the use case are summarized in Table A-6. Table A-6 also 
provides the allocation of the function in the current environment and in the MBT environment. 


Table A-6: Use Case SAA Reroute Functions and Allocation 


Function Current Allocation MBT Allocation 
Coordinate use of airspace ATCSCC ATCSCC 
ARTCC Traffic Management ARTCC Traffic Management 
Specialists Specialists 
Publish airspace ATCSCC ATCSCC 
constraints 
Apply constraints to ATCSCC ATCSCC 
aircraft trajectories 
File flight plan Dispatcher Dispatcher 
Request flight plan Pilot Dispatcher 
amendment Dispatcher Pilot 
Evaluate amendment Controller ARTCC/ATCSCC Traffic 
requests ARTCC Traffic Management Management Specialists 
Specialists 
Amend the flight plan Controller ARTCC Traffic Management 
ARTCC Traffic Management Specialist 
Specialist Controller 
Deliver amended clearance Controller Controller 
ARTCC/TRACON Traffic 
Management Specialist 


Notes on Proposed MBT Allocation 


The following paragraphs provide reasoning behind the proposed MBT allocation of some of 
the functions in Table A-6. Functions discussed in previous sections are not repeated here 
unless the consideration of responsibility assignment was expanded through evaluation of this 
use case. 
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Publish Airspace Constraints 


In the current environment, the ATCSCC and traffic management automation publish the 
FCAs and associated advisories. This process will be similar in the MBT environment. Each 
airspace constraint must be identified in a way that is machine- and human-readable so that 
traffic management and flight operator automation can ingest the airspace constraints and 
associate them with trajectory constraints. 

Importantly, when the SAA is reopened, the same process is used to publish the change in 
airspace constraints (in this case, the removal of a constraint). 


Apply Constraints to Aircraft Trajectories 


In the current environment, traffic management automation uses the FCAs identifying the 
airspace constraint associated with the military exercise to indicate closed airspace. Any flight 
plan that penetrates that airspace during the active times should be rejected. This would also be 
true in an MBT environment, but the rejection notification would include a reference to the 
violated airspace constraint (i.e., the FCA). 

FCAs are not always used to identify closed airspace as is done in this use case. Rather, 
FCAs are often used to moderate demand for a given region of airspace when demand is 
predicted to exceed capacity. In such cases, the traffic management automation uses the FCA 
along with demand predictions to apply Controlled Times of Arrival (CTAs) to aircraft predicted 
to use the airspace. These CTAs, in turn, are used to calculate Expect Departure Clearance 
Times (EDCTs) to which flight operators are expected to adhere. 

In an MBT environment, the traffic management automation would apply the CTA directly to 
the assigned trajectories and flight operators would then choose the departure time that would 
best allow them to meet the CTA. 

When the airspace is reopened and the FCA is canceled, the traffic management 
automation does not automatically act on any aircraft trajectories in the current environment, 
and it would not do so in the MBT environment. Rather, flight operators will be able to monitor 
changes in airspace constraints and may request an amendment to the assigned trajectory at 
any time. 


Request Flight Plan Amendment 


In the current environment, flight plan amendment requests for en route flights typically 
come from the pilot, although the dispatcher may coordinate reroutes in cases such as dynamic 
weather that is significantly downstream from the aircraft’s current location. In the MBT 
environment it is expected that there will be some distance from the Trajectory Change Point 
(TCP) at which the aircraft will be considered too close to the TCP for the trajectory amendment 
to be coordinated by the dispatcher (e.g., an aircraft already operating within the controller’s 
planning horizon). In such cases, the pilot will continue to request the trajectory amendment and 
not the dispatcher. Such requests will be downlinked to the controller. 

However, for flights that are farther from the TCP, the dispatcher will be able to request the 
trajectory amendment directly from the traffic management automation, which is expected to be 
capable of evaluating most requests and agreeing to the requested change, rejecting the 
request, and/or negotiating with the flight operator until an amended assigned trajectory is 
agreed upon. In fact, it is expected that Flight Operations Center (FOC) automation will be 
capable of requesting an amended trajectory and even negotiating with the traffic management 
automation on the flight operator’s behalf. 

Note that the Trajectory Options Set (TOS) associated with Collaborative Trajectory Options 
Program (CTOP) and flight operator and traffic management automation to manage TOS 
submission and evaluation are current-day examples of such capabilities. In the near- to mid- 
term MBT environment, it is expected that flight operators will be capable of maintaining an up 
to date TOS. Even when no CTOP is in place, the traffic management automation would 
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evaluate the TOS to determine whether the current set of airspace and trajectory constraints 
render a different trajectory on file to be preferred by the flight operator. 


Evaluate Amendment Requests 


One reason that reroutes are so time-consuming and difficult in the current environment is 
that there are several manual steps involved in receiving and evaluating flight operator reroute 
requests. In a scenario like the one described in this use case, each reroute request (for en 
route flights) must be received by a controller via voice, manually entered into the controller 
automation, and evaluated by the automation and the controller. Only a controller working in the 
affected ARTCC can process the reroute. This concentrates the workload associated with 
processing requests on a few controllers, creating a bottleneck that can lead to the controllers 
not accepting any reroute requests at all because they do not have time to process them. 

In an MBT environment, the flight operator can request the reroute at any time, allowing 
many of the reroute requests to be processed before the aircraft enters the affected ARTCC. 
The dispatcher sends these requests directly to the traffic management automation, which can 
evaluate the requested trajectory against known constraints. In many cases, the traffic 
management automation will be able to approve the requested route. Where necessary, the 
traffic management automation will request review by a traffic management specialist. The 
automation will need to have parameters indicating when to request traffic management 
evaluation, and which facility or facilities — e.g., which ARTCC or the ATCSCC — should do the 
evaluation. 

Note that use of the TOS as discussed above would imply that the traffic management 
automation periodically evaluates the TOS for each flight — even in the absence of a CTOP — to 
determine if a different trajectory in the TOS is acceptable and preferred. 


Amend the Assigned Trajectory 


In the current environment, the flight plan amendments for scenarios like that described in 
this case must be entered manually into the controller or traffic management automation by a 
controller or traffic management specialist. In an MBT environment, it is expected that traffic 
management automation can engage in trajectory negotiation with flight operators and can thus 
amend the assigned trajectory at the conclusion of the negotiation according to parameters set 
by the traffic management specialist. 

However, controller automation will not be expected to negotiate this kind of assigned 
trajectory amendment and therefore the controller would need to take a separate action to use 
the controller automation to evaluate and amend the assigned trajectory. Note that this is similar 
to the conflict avoidance maneuvers discussed above, in which the explicit action taken by the 
controller was to uplink a clearance to the aircraft and this action also triggered amendment of 
the assigned trajectory. 

Traffic management specialists will have equal authority to amend the assigned trajectory to 
what they have today, but it is expected that in the MBT environment they will be primarily 
responsible for managing the process by which the traffic management automation negotiates 
trajectories and amends the assigned trajectories. 


Dispatcher Requests Delayed Arrival for Gate Management 


In this use case, a dispatcher requests that a flight crew reduce in flight speed in order to 
delay their arrival time for gate management. However, the aircraft encounters higher than 
expected headwind and therefore absorbs more delay than expected. Furthermore, the extra 
delay pushes the aircraft into a heavy arrival bank that is exacerbated by weather. 
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Use Case Steps 


Present Day Procedures and Automation 


A, 


ts 


After an on-time departure from TPA, DAL610 receives an ACARS message from 
dispatch instructing the pilot to reduce speed to lose 15 minutes over the course of the 
flight due to a gate management issue upon arrival at MSP. The speed reduction is less 
than 10kts and does not require coordination with ATC. 


DAL610 encounters stronger than forecast upper level winds. 90 minutes into the flight, 
the pilot checks with dispatch. They’ve lost more than the desired 15 minutes, and so 
they resume normal speed. 


MSP weather transitions from M-VEFR to an IFR AAR of 52, and ZMP has extensive 
metering delays. ZMP passes back a 30 MIT restriction to ZAU. 


Due to the reduced speed plus strong headwind, DAL610 has slipped from a period of 
low arrival demand into the busiest arrival spike of the day at MSP — the 2230 bank. 


DAL610 gets slowed and turned to meet the 30 MIT pass-back restriction in ZAU 
airspace. 


Once inside ZMP airspace DAL610 receives two turns in the hold due to a 15 minute 
TBFM metering delay. 


DAL610 arrives at MSP 45 minutes late. 


Managed in an MBT Environment 


1. 


5. 


After DAL610 departs, the dispatcher is notified of a gate management issue at MSP, 
and submits a trajectory amendment request reflecting a reduced cruise speed (and 
hence a later ETA at the destination airport). The new trajectory is accepted by the traffic 
management automation and is sent to the controller for uplink to the aircraft. 


While en route, the ANSP ground automation detects that the aircraft is out of 
conformance with its assigned trajectory, operating slower than expected.?® The ground 
automation notifies the dispatcher and the controller, who in turn notifies the pilot that the 
flight is out of conformance with its assigned trajectory. 


. Alternatively, an onboard conformance monitoring capability detects that the aircraft is 


out of conformance and notifies the pilot that the aircraft is operating slower than 
expected. The pilot (or the aircraft automation) notifies the dispatcher. 


There are no time constraints associated with the assigned trajectory, and so the flight 
operator can choose whether to request an update to the assigned trajectory that 
maintains the current speed or to modify the aircraft behavior in order to maintain the 
current destination ETA. The dispatcher remodels the flight and advises the flight crew to 
increase the cruise speed to try to maintain the current destination ETA. 


Alternatively, the pilot could downlink a request for updated winds to FOC automation, 
which provides the uplink. The pilot loads the winds and remodels the assigned 
trajectory, identifying an appropriate speed to meet the desired arrival time, and 


18 Ground-based conformance monitoring could be done in a variety of ways, including monitoring 
ground speed relative to assigned trajectory speed, comparing downstream ETAs between the aircraft 
intent and the ground automation predicted trajectory, and monitoring vertical and lateral position relative 
to the assigned trajectory. 
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downlinks a request for that cruise speed to coordinate the amendment to the assigned 
trajectory. 


6. The pilot implements the new cruise speed and the next downlinked EPP report shows 
improved conformance with the assigned trajectory. 


7. MSP weather transitions from M-VFR to an IFR AAR of 52, and ZMP has extensive 
metering delays. The traffic management automation amends the assigned trajectory of 
DAL610 to include an STA that involves 10 minutes of metering delay. The traffic 
management automation uplinks the amended trajectory with a Required Time of Arrival 
(RTA) at the last merge fix before the meter fix directly to the aircraft. 


8. The traffic management automation notifies the dispatcher of the changes. The 
dispatcher coordinates with ramp control at MSP to ensure a gate will be available for 
this flight at its new arrival time. 


9. DAL610 complies with the RTA and arrives to MSP at 2250Z, 25 minutes later than the 
original ETA, with a gate available. 


A variation on this use case is one in which the aircraft is not equipped to downlink the 
predicted trajectory, which will make it more difficult for the ground automation to detect 
nonconformance. 


Use Case Assumptions 


This use case assumes that the flight operator is required to coordinate the reduced speed 
and/or desire to arrive to the airport later with the ANSP. Although the aircraft in this case is not 
subject to any time constraints at the time the flight operator chooses to reduce speed, 
managing aircraft on a 4DT will require time and/or speed conformance. 

In addition, this use case assumes that the ANSP ground automation and/or aircraft 
automation has a conformance monitoring capability that compares the aircraft/flight operator 
predicted trajectory with the assigned trajectory. The ground-based conformance monitoring 
capability would also compare the aircraft/flight operator predicted trajectory with one or more 
ground automation predicted trajectories. 

In this case, the assigned trajectory does not have any time constraints that will be violated 
by the reduced ground speed. Thus, in response to the nonconformance, the flight operator can 
choose whether to update the assigned trajectory to meet the current aircraft performance or to 
modify the aircraft’s behavior to meet the assigned trajectory. 

Also, time based metering is used to manage the delays associated with the reduced AAR 
and not MIT. Although choice of TMI is out of scope of MBT, it is expected that improved 
trajectory predictions associated with MBT will make time based metering more accurate and 
therefore more likely to be used to manage dynamic airspace constraints. 


Use Case Functions and Allocation 


The functions identified in the use case are summarized in Table A-7. Table A-7 also 
provides the allocation of the function in the current environment and in the MBT environment. 


Table A-7: Trajectory Conformance Use Case Functions and Allocation 


Function Current Allocation MBT Allocation 
Plan aircraft trajectory Dispatcher Dispatcher 

Pilot Pilot 
Monitor conformance with __ Pilot Pilot 
the flight plan/assigned Controller Controller 
trajectory 
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Resolve nonconformance Controller Pilot 
Pilot Dispatcher 

Controller 
Publish airspace ARTCC/ATCSCC Traffic ARTCC/ATCSCC Traffic 
constraints Management Specialist Management Specialist 
Apply constraints to Controller ARTCC/ATCSCC Traffic 
aircraft Management Specialist 
Amend the assigned N/A ARTCC/ATCSCC Traffic 
trajectory Management Specialist 
Deliver clearance Controller Controller 

ARTCC/ATCSCC Traffic 

Management Specialist 


Notes on Proposed MBT Allocation 


The following paragraphs provide reasoning behind the proposed MBT allocation of some of 
the functions in Table A-7. Functions discussed in previous sections are not repeated here 
unless the consideration of responsibility assignment was expanded through evaluation of this 
use case. 


Monitor Conformance with the Assigned Trajectory 


In the current environment, pilots are primarily responsible for operating the aircraft in 
conformance with the clearances provided by the controller, including the flight plan, and 
notifying the controller of the intent to deviate from this shared plan. Some operations already 
require aircraft to be equipped to monitor conformance with various aspects of a trajectory. For 
example, Required Navigation Performance (RNP) requires conformance monitoring with a 
lateral path, and time of arrival control (TOAC) requires monitoring conformance with an arrival 
time at a waypoint. In both cases, the pilot is notified when the aircraft is UNABLE. Similarly, 
vertical navigation (VNAV) provides the pilot information consistent with the spirit of 
conformance monitoring. In such cases, the pilot is responsible for either adjusting operation of 
the aircraft to return to conformance, or coordinating an alternative with the controller. 

Controller automation also monitors the aircraft trajectory for conformance with the flight 
plan in order to support sector controllers in coordinating the handoff. It is not concerned with 
downstream ETAs. In this use case, the downstream ETAs are not constraints on the assigned 
trajectory; rather, they are estimates used by the various automation systems for planning 
purposes. In a previous focus group with pilots, the concept of onboard versus ground 
responsibility for conformance monitoring was explored.*® Participants in that activity stated that 
they would prefer to be notified first of nonconformance, before the controller, allowing them the 
Opportunity to correct the nonconformance and coordinate with the dispatcher as needed. They 
noted that downlinked aircraft intent would include the nonconforming trajectory, and so there 
would not be much time between the pilot notification and the controller and dispatcher 
notification. 

This (limited) feedback from pilots is consistent with TBO concepts in which the 4DT is 
considered a contract between the ANSP and the flight operator, and consistent with a goal of 
MBT that aircraft follow the assigned trajectory without controller intervention. Thus, the pilot is 


19 A, Fernandes, S. Vail, J. Rebollo and J. Brown, "Oceanic Flights and Airspace: Improving Efficiency 
by 4-Dimensional Trajectory-Based Operations Year End Report," Mosaic ATM, Inc., Leesburg, VA, 
2015. 
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given primary responsibility for trajectory conformance, including conformance monitoring. This 
also gives the pilot primary responsibility for resolving trajectory nonconformance, as discussed 
in the next section. 

However, a key aspect of this use case is the stronger than predicted headwind. In sucha 
case, not only does the aircraft have a low-resolution wind forecast, but that forecast is 
incorrect. Ground automation, on the other hand, uses surveillance data to monitor the aircraft 
ground speed and has higher resolution winds than the aircraft. In this case, the ground 
automation may more quickly detect the trajectory nonconformance, particularly as it uses 
trajectory predictions to monitor demand at the downstream constrained resource. Further, the 
controller is ultimately responsible for separation management, which requires close monitoring 
of trajectory conformance. 

Thus, it is clear that a ground automation conformance monitoring capability is required, in 
addition to onboard automation, to support controllers and traffic managers in achieving MBT. 
However, additional research is necessary to determine whether this should be a standalone 
capability or if it should be incorporated into one or more other automation systems (e.g., traffic 
management and/or controller automation). 


Resolve Trajectory Nonconformance 


In the current environment, detecting and resolving trajectory nonconformance is not as 
important as it is expected to be in an MBT environment, particularly in the time dimension. To 
the extent that a controller identifies trajectory nonconformance as an issue, the controller will 
provide instructions to the aircraft that will return it to its flight plan route. In the process, the 
controller may ask the pilot to explain the situation. 

Managing aircraft by trajectories requires that there is a consistent view across all 
participants and automation systems of the aircraft's planned trajectory. When nonconformance 
is detected, the pilot will have the most information about the reason for the nonconformance in 
most cases. A significant delay due to a poor wind forecast such as in this use case is an 
exception. In such a case, the dispatcher and controller will likely have access to better 
information about the winds. 

Since the pilot is expected to have the most information about the reason for the 
nonconformance, as well as the most information about what the aircraft can do to resolve the 
nonconformance, the pilot is allocated primary responsibility for this function in the MBT 
environment. However, the dispatcher in many cases has access to relevant information such 
as all of the published NAS data reflecting the ground system trajectory predictions, the aircraft 
data, and the flight operator preferences to determine how to resolve the nonconformance. 
Thus, the dispatcher is allocated secondary responsibility. Note that flight operators typically 
have procedures in place for pilot-dispatcher coordination when route amendments are needed, 
and it is expected that each flight operator organization will identify situations in which the pilot 
or the dispatcher has primary responsibility for this function. The key for MBT is that automation 
to support trajectory conformance monitoring, trajectory amendment, and negotiation must be 
able to accommodate either pilot or dispatcher participation in this function. 

However, not all aircraft are supported by a dispatcher. In such cases, the pilot will need to 
resolve the nonconformance, possibly by explaining the situation to ATC. If the pilot is unable to 
resolve the nonconformance, the controller may need to intervene to ensure that the aircraft and 
ground automation have all of the appropriate data to ensure consistent trajectory predictions. 


Use of CTOP to Manage Multiple Dynamic Airspace Constraints 


In this use case, a CTOP is used to manage a large, dynamic weather event that 
significantly disrupts NAS operations. 
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Use Case Steps 


The long-range CCFP forecast indicates that a large area of thunderstorms will develop in 
the middle of ZKC within the next 24 hours. The ATCSCC PERTI Advanced Planning Team 
plans a CTOP TMI to manage the east/west flow of traffic for the following day. Flight operators 
participate on all planning teleconferences and begin planning their TOS options. 

The following morning, the ATCSCC Traffic Managers work with the field TMUs and flight 
operators to determine the best FCA location and start/stop times, including both impact FCAs 
and adjacent (monitoring) FCAs. The CTOP TMI advisory is published and discussed on 
subsequent planning teleconferences. 


Present Day Procedures and Automation 


dL: 


10. 


11. 


Flight operators submit a TOS for each flight affected by the CTOP. They continually 
revise and re-submit their TOS options, including substitutions, right up until 45 minutes 
prior to p-time. In the current environment, all TOS options are delivered pre-departure. 


The FCA rates and start/end times are finalized and the TMI begins. The CTOP 
algorithm (in TFMS) distributes EDCTs and reroutes to meet the FCA throughput rates. 


The FOCs file their “awarded flight plans”, but they continue to revise and resubmit, and 
the CTOP algorithm continues to re-evaluate the TOS, until 45 minutes prior to p-time. 


The ABC Airlines FOC files the awarded flight plan for flight ABC123 from EWR to LAX, 
a route around the northern side of the FCA that was given less delay than the preferred 
route through the FCA. 


Up until departure, the flight crew and FOC exchange flight plan information according to 
company SOP 


. ATCSCC and ARTCC traffic management specialists monitor the weather impact on 


traffic flows and sector volumes as the thunderstorms develop and conditions change. 
The ATCSCC continually dials capacity levels up and down based on comparing the 
forecast weather with the actual thunderstorm development. 


The increased capacity for the FCA causes the route/delay for ABC123 to be modified, 
causing the preferred route through the FCA to be the top ranked route in the TOS. 


After a 12-minute ground delay to meet its EDCT, ABC123 departs on the preferred 
route, which traverses the FCA. 


. While flight ABC123 is en route over PIT (in ZOB) the weather cells in ZKC develop 


more intensely and further north than forecast. This means that the FCA rates were set 
too aggressively and they are dialed down. This causes dozens of unplanned, last- 
minute airborne reroutes. In the adjacent regions on either side of the primary FCAs, 
there is a cascading effect of unplanned traffic volume, and additional flights (previously 
not impacted by weather) need to be moved further north and south, away from sectors 
that have now gone “red”. 


ABC123 requires a reroute around the FCA. An ARTCC traffic management specialist 
manually enters a reroute for the flight into the controller automation. The reroute is 
delivered to the controller workstation for the sector where the aircraft is currently 
Operating. 


As the CTOP event concludes, the ARTCC and ATCSCC traffic management specialists 
continue to monitor the weather impact on all sector monitor alert parameter (MAP) 
values and begin to dial demand back up to match available capacity (i.e., create an exit 
strategy for the CTOP), and eventually traffic is returned to normal. 
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12. 


Numerous large-scale tactical reroutes and several close-in, short-haul ground stops 
were required in addition to the CTOP to manage the event, which is a very challenging 
day in the NAS. The FOCs have cancelled dozens of flights and now work diligently to 
recover their operations. 


Note: This is a realistic depiction of how NAS-altering weather events occur today and how 
they are expected to occur during early deployment of CTOP TMIs, prior to the introduction of 
PDRR/ABRR. The alternative version of this Use Case would be to use an overly aggressive 
approach where the FCA rates are set too high and the over-restrictions slow the NAS toa 
snail's pace. The NAS then experiences a large amount of unrecoverable delay. 


Managed in an MBT Environment 


a 
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Flight operators submit a TOS for each flight affected by the CTOP. They continually 
revise and re-submit their TOS options, including substitutions, until a more desirable 
route is no longer an option (e.g., the flight has passed the affected airspace). In the 
future environment, TOS options are delivered pre-departure (via PDRR) as well as 
while flights are airborne (via ABRR). 


The FCA rates and start/end times are finalized and the TMI begins. The CTOP 
algorithm (traffic management automation) distributes CTAs at the FCA boundary and 
reroutes to meet the FCA throughput rates. 


Each time a flight’s CTA at the FCA boundary changes or the preferred route in its TOS 
changes, the traffic management automation notifies the FOC and negotiation begins to 
amend the assigned trajectory. Each flight operator will determine the appropriate level 
of automation to support this negotiation on their behalf, but it is expected that most 
FOCs will have automation support for evaluating the ANSP-proposed amendment and 
agreeing to or rejecting the amendment (or notifying a dispatcher and/or ATC 
coordinator that a review is required). 


The ABC Airlines FOC agrees to an assigned trajectory for flight ABC123 from EWR to 
LAX involving a TOS option around the north side the FCA that has less delay than the 
preferred route through the FCA. 


Up until departure, the flight crew and FOC exchange flight plan information according to 
company SOP. 


. ATCSCC and ARTCC traffic management specialists monitor the weather impact on 


traffic flows and sector volumes as the thunderstorms develop and conditions change. 
The ATCSCC continually dials capacity levels up and down based on comparisons 
between the forecast weather with the actual thunderstorm development. 


The increased capacity for the FCA causes the route/delay for ABC123 to be modified, 

causing the preferred route through the FCA to be the top ranked route in the TOS. The 
assigned trajectory for ABC123 is modified to include the preferred route as well as the 

CTA at the FCA boundary. 


. ABC Airlines determines that the best way to meet the CTA at the FCA boundary is to 


absorb 12-minutes of delay on the ground. After this 12-minute delay, ABC123 departs 
on the preferred route, which traverses the FCA. 


. While flight ABC123 is en route over PIT (in ZOB) the weather cells in ZKC develop 


more intensely and further north than forecast. This means that the FCA rates were set 
too aggressively and they are dialed down. This causes dozens of unplanned, last- 
minute airborne reroutes. In the adjacent regions on either side of the primary FCAs, 
there is a cascading effect of unplanned traffic volume, and additional flights (previously 


not impacted by weather) need to be moved further north and south, away from sectors 
that have now gone “red”. 


10. ABC123 requires a reroute around the FCA. The traffic management automation 
evaluates its TOS (which the ABC FOC has kept up to date with its preferences for 
airborne reroutes and delay) and identifies a route that satisfies the updated NAS 
constraints. The traffic management automation notifies the FOC of the reroute and also 
distributes the amendment to the controller workstation where the aircraft is currently 
located. The controller delivers the clearance to the aircraft, the flight crew evaluates and 
accepts the route, and the assigned trajectory is amended. 


11. As the CTOP event concludes, the ARTCC and ATCSCC traffic management specialists 
continue to monitor the weather impact on all sector monitor alert parameter (MAP) 
values and begin to dial demand back up to match available capacity (i.e., create an exit 
strategy for the CTOP), and eventually traffic is returned to normal. 


12. To the extent that amending the assigned trajectories for flights that are airborne and 
pre-departure does not sufficiently manage demand, traffic management retains the 
flexibility to make use of ground stops and other tactical traffic management initiatives. 
However, the ability to accurately predict traffic demand and efficiently negotiate 
assigned trajectory amendments for airborne flights reduces the need to employ these 
measures. Note that there still must be a recovery process for flight operators, but it is 
not expected to be as severe in an MBT environment. 


In one variation to this use case, the FOC evaluates the amendment to the assigned 
trajectory in Step 10 and decides to negotiate an alternative. ANSP trajectory negotiation 
automation makes this possible; in the current environment the manual workload associated 
with such requests would make it infeasible in a scenario like this. 


Use Case Assumptions 


This use case assumes that PDRR and ABRR are available in the future environment. Note 
that these concepts are separate from the MBT concept but are part of the MBT operational 
environment. MBT leverages them to support efficient amendment of assigned trajectories. 

Also note that the use of CTOP as a TMI and the selection of rates, etc., is outside the 
scope of MBT. MBT provides the mechanism to apply the constraints associated with the TMI to 
the assigned trajectories as conditions change. 

The use case also assumes that trajectory constraints associated with a TMI can be applied 
directly to the assigned trajectory. In the use case, the CTOP TMI assigns CTAs at the FCA and 
then translates them into EDCTs to ensure that the aircraft incur as much of the delay as 
possible on the ground. MBT envisions assigning the CTA at the constraint point directly to the 
assigned trajectory, and allowing flight operators to choose the appropriate amount of ground 
delay to allow them to fly a closer to optimal trajectory to the constraint point. Note that 
mechanisms must be put in place to prevent flight operators gaming the system by assuming 
they can take all necessary delay in the air. 


Use Case Functions and Allocation 


The functions identified in the use case are summarized in Table A-8. Table A-8 also 
provides the allocation of the function in the current environment and in the MBT environment. 


Table A-8: CTOP TMI Use Case Functions and Allocation 


sUlarer ace} (Oli accyal@mAlifeler-hitelal WiL=M MAI Celer-tatelal 
Manage CTOP TMI ATCSCC/ARTCC Traffic ATCSCC/ARTCC Traffic 


Management Specialist Management Specialists 
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Publish airspace ATCSCC Traffic ATCSCC Traffic 
constraints Management Specialist Management Specialist 
Apply constraints to ATCSCC Traffic ATCSCC Traffic 
aircraft trajectories Management Specialist Management Specialist 
Submit TOS Dispatcher Dispatcher 
Maintain and update TOS Dispatcher Dispatcher 
Pilot Pilot 
File “awarded flight plan” Dispatcher N/A 
Negotiate assigned ATCSCC/ARTCC Traffic ATCSCC/ARTCC Traffic 
trajectory amendments Management Specialist (Pre- Management Specialist 
departure) Dispatcher/ATC Coordinator 
Dispatcher/ATC Coordinator 
(Pre-departure) 
Plan reroute ARTCC Traffic Management ARTCC Traffic Management 
Specialist Specialist 
Dispatcher 


Notes on Proposed MBT Allocations 


Note that there are few differences in the allocation of roles and responsibilities between the 
current environment and the MBT environment in this use case. Improvements in the MBT 
environment are largely driven by enhanced automation capabilities, including some that are 
outside the scope of the MBT concept. 


Maintain and Update TOS 


In the current (or near-future) environment, flight operators have automation to support 
dispatchers in maintaining and resubmitting the TOS as conditions and preferences change. 
This automation is primarily responsible for this function. The dispatcher (and/or ATC 
coordinator) is the responsible participant. 

While the pilot does not submit TOS options, the pilot does coordinate preferences and 
options with the dispatcher. The pilot should be in the decision-making loop and therefore is 
included as a participant with responsibility for this function. 

The allocation of responsibility ostensibly does not change in the MBT environment. 
However, the expanded access to information and automation capabilities on the flight deck 
may increase the role of the pilot. It is conceivable that advanced aircraft automation can 
support TOS maintenance. 


File Awarded Flight Plan 


In an MBT environment, once the flight operator submits the TOS, the top-ranked trajectory 
can automatically be set as the assigned trajectory for a flight. This eliminates the need for the 
dispatcher to take the extra step of filing a flight plan based on the TOS. Flight plan filing and 
negotiation can be managed as continual evaluation and management of the TOS. 


Negotiate Assigned Trajectory Amendments 


The allocation of roles and responsibilities is not expected to change significantly between 
the current environment and the MBT environment, but the negotiation will be handled 
differently. In the current environment, the CTOP algorithm (traffic management automation) 
selects the preferred TOS option and offers it to the FOC, which evaluates and then re-files the 
newly awarded trajectory. In the future environment, more of the negotiation is expected to be 
handled by automation, and it is not expected that the dispatcher/ATC coordinator will need to 
re-file the awarded TOS option. 
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One cognitive walkthrough participant suggested considering the use of a TOS at all times 
even in the absence of a CTOP program. Negotiation via the TOS would work the same way 
whether there was an active CTOP or not. This implies that the allocation of responsibility for 
trajectory negotiation would be consistent with that proposed for this use case in many other 
use cases as well. 


Plan Reroute 


In the current environment, airborne reroutes require a traffic management specialist to 
manually enter the reroute. In addition to other efforts to increase automation support for 


managing airborne reroutes, this use case takes advantage of the TOS and traffic management 
automation that is already designed to manage changes to the preferred trajectory option after 


departure. A key part of this is FOC automation that keeps the TOS up to date throughout the 


life of the flight, adding responsibility to the dispatcher for ensuring that the TOS is appropriately 


maintained. 
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